JDK-8027915 : TestParallelHeapSizeFlags fails with unexpected heap size
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs25,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: generic
  • Submitted: 2013-11-06
  • Updated: 2016-01-12
  • Resolved: 2014-06-24
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
9 b23Fixed
Related Reports
Cloners :  
JDK-8049864 - TestParallelHeapSizeFlags fails with unexpected heap size
Relates :  
JDK-8028254 - gc/arguments/TestMinInitialErgonomics.java failed with unexpected initial heap size
Relates :  
JDK-8048877 - VM warning "Attempt to use MPSS failed" on Solaris SPARC
Relates :  
JDK-8044132 - Quarantine unstable/broken GC tests
Description
Running the test on sparcv9 fails with this exception:
java.lang.RuntimeException: Heap has 8388608 bytes, expected to be less than 4194304
	at TestMaxHeapSizeTools.checkGenMaxHeapSize(TestMaxHeapSizeTools.java:254)
	at TestMaxHeapSizeTools.checkGenMaxHeapErgo(TestMaxHeapSizeTools.java:109)
	at TestParallelHeapSizeFlags.main(TestParallelHeapSizeFlags.java:46)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:744)
Comments
The problem is os::page_size_for_region, in particular the check: if ((region_min_size & mask) == 0 && (region_max_size & mask) == 0) If page_size_for_region is called with min_region_size and max_region_size that are a multiple of a page size larger than than max_page_size, then page_size_for_region will return that page. This problem manifests itself on Solaris using large pages. Solaris will use a page size of 2 MB. If -Xmx4m is used, then GenerationSizer::initialize_size_info will call page_size_for_region(4MB, 4MB, 8 /* min_pages*/). Since 4MB is a multiple 2MB, page_size_for_region will return 2MB. The bug is that we ask for at least 8 pages, which would limit the page size to 4MB/8 = 0.5MB (512 KB). Since parallel scavenge needs at least 4 pages, we get a heap size 4 * 2MB = 8MB, even though the user specified -Xmx4m!
24-03-2014
Release team: Approved for deferral.
06-12-2013
SQE approves deferral.
03-12-2013
8-defer-justification: This is a bug in the test, not in the VM code. The VM code has been updated, and is working as expected, but the test has not been updated. This has no impact on the released product.
03-12-2013
The other is also a test bug, I've updated it with more information.
13-11-2013
Stefan J., I don't get the way that gc/arguments/TestMinInitialErgonomics.java (the other failure you reported here) failed; it seems that the heapsize should be properly aligned and pass that test. And, I couldn't reproduce it. So, I've created a new CR JDK-8028254 to keep track of it, P4.
13-11-2013
VM has the right behavior; it's a test bug, not reflecting large page alignment.
12-11-2013
It does not matter for the test as long as Xmx is below 8M: the VM requires in all cases that minimum heap size for parallel gc is 2x page size. When large pages are used on sparc, with its large page size of 4M this results in an 8M minimum heap. There does not seem to be a regression in the VM behavior, JDK-8016309 only improved reporting of actual heap size.
08-11-2013
Note that the test actually failed on the case of -Xmx3M. Please refer to .jtr file.
08-11-2013
One of the recent changes to the collector policies, but most likely JDK-8016309 causes the issue. See collectorPolicy.cpp line 292/293: it first calculates the minimum young gen size, which is aligned to _gen_alignment, and then adds a single _gen_alignment; and also GenerationSizer::initialize_size_info() where _gen_alignment is recalculated after an initial pass using os::page_size_for_region() and the calculation redone with the new _gen_alignment. If you look at os::page_size_for_region(), it will return 4M with large page size of 4M as it is the "The largest page size with no fragmentation.". During above mentioned recalculation of the heap, it will get expanded to 8M, resulting in the crash. Imo either os::page_size_for_region() should take into account that the heap needs to fit into at least two pages (i.e. do not select a single 4M page for heaps of the same size), or maybe that page_size_for_region() sets the heap alignment, not the generation alignment. Not sure if the second solution gives the correct result as I remember that previously parallel scavenge used the os::page_size_for_region() result as generation alignment too. Not sure why/how it worked out before that change. From brief inspection it did not: the code also reserved a space of at least two (large) pages too. The difference is that earlier code did not update the collector policy variables the test checks against. It looks as if this error/behavior has been hidden until now because of program bugs. I just ran an old java version with "java -XX:+UseParallelGC -XX:+PrintGCDetails -Xmx4M -XX:+UseLargePages -version", and the real total heap size is 8M too. Heap PSYoungGen total 3584K, used 347K [0x00000000ffc00000, 0x0000000100000000, 0x0000000100000000) eden space 3072K, 11% used [0x00000000ffc00000,0x00000000ffc56e90,0x00000000fff00000) from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000) to space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000) ParOldGen total 4096K, used 0K [0x00000000ff800000, 0x00000000ffc00000, 0x00000000ffc00000) object space 4096K, 0% used [0x00000000ff800000,0x00000000ff800000,0x00000000ffc00000) I.e. this looks like a test bug.
07-11-2013
Do you recall which changeset made that change, Thomas?
07-11-2013
Current theory is that the recent changes to the collector policy changed heap sizing so that the minimum total heap size must be 2x large page size, ie. one page per generation, for parallel gc. One sparc large page size can be one of 64k, 4M, 256M and 2G(?), hence the minimum heap size of 8M.
07-11-2013
This bug needs more investigation to figure out if we just need to update the test or if this is a real bug. Current ILW: MMH => P3 Impact: Medium, get larger heap than expected. Might be bad on embedded. Likelihood: High, with the given configuration it happens each run on sparc. Workaround: High, unknown. (Using larger heap doesn't count)
07-11-2013