Hi Kevin,
On 2017-08-22 16:38, Kevin Walls wrote:
Hi,
jcmd GC.run to invoke GC fails if -XX:+DisableExplicitGC is set: this
seems like a mistake?
This behaviour is obstructive for a live app that _needs_ a GC, and was
started with -XX:+DisableExplicitGC.
DisableExplicitGC to protect from Java code calling System.gc frequently
makes sense, but if I can attach and run a dcmd, I should have
permission to inspect and maintain the JVM, including invoking a GC.
(This is as the user who owns the process and can kill it off.)
The behaviour (checking DisableExplicitGC in SystemGCDCmd::execute)
comes in with:
https://bugs.openjdk.java.net/browse/JDK-8004095
8004095: Add support for JMX interface to Diagnostic Framework and Commands
The JMX relation I suppose suggests we didn't want JMX to override
DisableExplicitGC by way of using a jcmd/DCmd.
But also, we now have:
8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc()
Summary: GCCause which is caused by GC.run diagnostic command should be
different from System.gc() .
..at least the causes are distinct.
I don't think we document this clearly. Our comment in globals.hpp is
""Ignore calls to System.gc()". I don't think we say anywhere that jcmd
is subject to being disabled by the flag.
Interested to hear any reason in favour of the current behaviour! If
there's nothing, I'll log a bug and ask for review of the change to
remove it...
There were some discussions earlier around this area and I came up with
the idea of having a "force" option to the GC.run command to override
DisableExplicitGC.
The comments in globals.hpp are a notoriously bad spec for the flags
since they are only ever present in debug builds of the JVM.
Thanks
/Mikael
Thanks
Kevin
