JDK-8012591 : Flags shown by jmap are not updated after argument processing and ergonomics handling
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2013-04-18
  • Updated: 2016-06-21
  • Resolved: 2016-06-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Blocks :  
JDK-8048093 - Explicitly setting := vs = in the -XX:+PrintFlagsFinal output
Relates :  
JDK-7057939 - jmap shows MaxNewSize=4GB when Java is using parallel collector
Description
The jmap tool prints the values of some global flags with the -heap option.

These flags partially do not correspond to the values determined after argument and ergonomics handling.

At least OldSize and SurvivorRatio are not updated if not set explicitly on the command line.

Also look at other flags of the jmap tool (see <hotspot-base>/agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java) whether they are up to date after argument/ergonomics handling.
Comments
There have been several cleanups made in the CollectorPolicy code since this bug was created, and it seems these cleanups have fixed this issue. I have verified that all the flag values printed by jmap are the same as those printed by -XX:+PrintFlagsFinal for a number of combinations of different options and GCs. As for SurvivorRatio vs InitialSurvivorRatio and MinSurvivorRatio I'm not sure how to interpret the bug. If SurvivorRatio isn't used by ParallelScavenge it seems to me that the bug is that jmap prints this flag when using ParallelScavenge. It does not make sense to me to update SurvivorRatio to any of Initial or MinSurvivorRatio only for the purpose of printing it in an external tool.
21-06-2016
Also try to refactor tests in tests/gc/arguments a little since the test helpers can be reused.
30-04-2013
The inconsistency of the parallel gc (Initial, Min)SurvivorRatio variables to SurvivorRatio has apparently been introduced with revision 352, i.e. somewhat before jdk7-b36, i.e. hs14b05.
19-04-2013
Originally reported by K. Mok on the hotspot-gc-dev mailing list. Paper trail: For SurvivorRatio, the handling in ParallelScavenge is a little bit different than other collectors in HotSpot. The collectors in the Generational GC framework and G1 use SurvivorRatio directly, so the value shown by jmap is the one that's taking effect. But ParallelScavenge doesn't use SurvivorRatio directly, instead it uses IntialSurvivorRatio and MinSurvivorRatio, with the latter two set ergonomically when the former is set explicitly. So with ParallelScavenge the SurvivorRatio value shown in jmap might not reflect what's really taking effect. On Thu, Apr 18, 2013 at 9:13 PM, Thomas Schatzl wrote: Hi, On Thu, 2013-04-18 at 02:33 +0800, Krystal Mok wrote: > Hi Thomas, > > Could the same kind of update be done for OldSize and SurvivorRatio? > For OldSize, if it's not explicitly set then it'll always show a > default value which is like 5MB or something, regardless of the > collector used. Going with the naming convention, OldSize would show the initial old generation size. > For SurvivorRatio, when using UseParallelGC or UseParallelOldGC, if > it's not explicitly set then InitialSurvivorRatio is the flag that > actually takes effect. It's better if SurvivorRatio could be updated > accordingly too. I think all collectors show these problems, just like in the MaxNewSize case. I created a CR which will become available later at http://bugs.sun.com/view_bug.do?bug_id=8012591 . It is a bit more generic as it requests to look at the other flags directly printed by jmap as well. Hth, Thomas
18-04-2013