search

oracle / visualvm

VisualVM is an All-in-One Java Troubleshooting Tool
https://visualvm.github.io/
Other
2.82k stars 297 forks source link

Constant memory allocation with VisualVM attached #506

Open woj-tek opened 1 year ago

woj-tek commented 1 year ago

Describe the bug Whenever VisualVM is attached, there is a constant memory usage growth (later collected) resulting in "chainsaw" graph. Disconnecting VisualVM stops the issue

To Reproduce Steps to reproduce the behavior: Connect VisualVM (and ideally other tool that monitors heap usage) and observer.

Expected behavior VisualVM connection should not impact (too much) heap usage

VisualVM log messages.log There are some exceptions but I'm not sure those are relevant

Screenshots When VisualVM is running and attached to the JVM process (proces not doing anything)

VisualVM-saw

While in YourKit: at 12:27 PM I attached VisualVM (allocations starts) and around 12:35 PM I disconnected it (allocations stops)

yourkit-with-without-visual-vm

Profiling in VisualVM (while attached, and it's happening) seems to point in JMX direction (?!):

visualvm-trace

Desktop (please complete the following information):

Additional context It's been happening for as long as I remember and was using VisualVM (at least 5-10 years?)

thurka commented 1 year ago

Right, this is expected. As you discovered, the allocations are caused by JMX, since it is written in java (take a look at jdk sources).

woj-tek commented 1 year ago

So it's virtually a "feature" (bug?) in JMX? Is it known/expected? Is there any possibility to improve it - it's somewhat annoying and in first instance can cause slight panic that there may be some sort of leak? (I tried searching but there doesn't seem to be any indication in JDK about anything related to it).

I assume that YourKit doesn't use JMX to monitor the JVM hence the issue is not present there?

thurka commented 1 year ago

So it's virtually a "feature" (bug?) in JMX?

I don't think this is a bug. It is a way Java works.

Is it known/expected?

Yes, I already wrote that this is expected.

Is there any possibility to improve it - it's somewhat annoying and in first instance can cause slight panic that there may be some sort of leak? (I tried searching but there doesn't seem to be any indication in JDK about anything related to it).

This "chainsaw" graph is not indication of leak if the allocated memory is freed and the low point of the "chainsaw" graph remains the same. This "chainsaw" graph is produced by most of the running java allipcations. It the most cases any running java code allocates some objects, which together with the way GC works, creates this "chainsaw" graph.

I assume that YourKit doesn't use JMX to monitor the JVM hence the issue is not present there?

Yourkit is profiler, so this is a liitle bit different case and JMX is not needed to get info from JVM, since yourkit own agent is running inside profiled JVM. BTW: I see the memory increases in your screenshot even when VisualVM is not connected, so issue is present there too.

If you want to monitor your appilcation without JMX, you can start your monitored application with: -Dsun.rmi.transport.tcp.maxConnectionThreads=0

you will still be able to use other monitoring APIs to get heap dump, thread dump, JFR etc., but there will not be any additional java code running in your monitored application and in your case, memory graph should be flat.

If you don't want any code to be invoked by VisualVM monitoring, you can run your application with: -XX:+DisableAttachMechanism