Constant memory allocation with VisualVM attached

[woj-tek]

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)

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

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

Desktop (please complete the following information):

• OS: MacOS Ventura 13.3.1
• JDK version: 17.0.4; OpenJDK 64-Bit Server VM (17.0.4+8-jvmci-22.2-b06, mixed mode, sharing
• Version 2.1.g

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

[thurka]

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]

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]

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