-
Bug
-
Resolution: Fixed
-
P3
-
None
-
b23
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8273667 | 8u321 | Fairoz Matte | P3 | Resolved | Fixed | b01 |
jcmd GC.run to invoke GC fails if -XX:+DisableExplicitGC is set: this seems like a mistake as it 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 current behaviour (checking DisableExplicitGC in SystemGCDCmd::execute) came in with
JDK-8004095: Add support for JMX interface to Diagnostic Framework and Commands
..which is in jdk8 onwards. This bug is saying we should move back to the JDK7 behaviour where the GC.run was not blocked by 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 current behaviour (checking DisableExplicitGC in SystemGCDCmd::execute) came in with
..which is in jdk8 onwards. This bug is saying we should move back to the JDK7 behaviour where the GC.run was not blocked by DisableExplicitGC.
- backported by
-
JDK-8273667 jcmd GC.run should not be blocked by DisableExplicitGC
- Resolved
- links to
-
Review openjdk/jdk8u-dev/40