JDK-7000125 : CMS: Anti-monotone young gen sizing with respect to maximum whole heap size specification
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-11-15
  • Updated: 2011-04-25
  • Resolved: 2011-04-25
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 7 Other
7Fixed hs21Fixed
Related Reports
Relates :  
Description
Shane Cox has reported the following bug on OpenJDK:-



-------- Original Message --------
Subject: 	Setting Min and Max Heap Size to the same value affects size 
of Young Gen
Date: 	Fri, 12 Nov 2010 14:31:53 -0500
From: 	Shane Cox <###@###.###>
To: 	###@###.###



This is probably well known behavior, but why does setting the Min and 
Max Heap Size to the same value affect the default size of the Young 
Generation?  For example:

Scenario 1:
-d64 -Xms1536m -Xmx4096m -XX:+UseConcMarkSweepGC

Young Generation is small:  18,624K

{Heap before GC invocations=0 (full 0):
 par new generation   total 18624K, used 16000K [0xfffffd7ef4e00000, 
0xfffffd7ef62c0000, 0xfffffd7f05c60000)
  eden space 16000K, 100% used [0xfffffd7ef4e00000, 0xfffffd7ef5da0000, 
0xfffffd7ef5da0000)
  from space 2624K,   0% used [0xfffffd7ef5da0000, 0xfffffd7ef5da0000, 
0xfffffd7ef6030000)
  to   space 2624K,   0% used [0xfffffd7ef6030000, 0xfffffd7ef6030000, 
0xfffffd7ef62c0000)
 concurrent mark-sweep generation total 1551616K, used 0K 
[0xfffffd7f05c60000, 0xfffffd7f647a0000, 0xfffffd7ff4e00000)
 concurrent-mark-sweep perm gen total 21248K, used 7265K 
[0xfffffd7ff4e00000, 0xfffffd7ff62c0000, 0xfffffd7ffa200000)
2010-11-12T14:00:16.083-0500: 0.364: [GC 0.364: [ParNew: 
16000K->2150K(18624K), 0.0048839 secs] 16000K->2150K(1570240K), 
0.0049538 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]



Scenario 2:
-d64 -Xms1536m -Xmx1536m -XX:+UseConcMarkSweepGC

Young Generation is much larger:  172,032K

{Heap before GC invocations=0 (full 0):
 par new generation   total 172032K, used 147456K [0xfffffd7f94e00000, 
0xfffffd7fa0e00000, 0xfffffd7fa0e00000)
  eden space 147456K, 100% used [0xfffffd7f94e00000, 0xfffffd7f9de00000, 
0xfffffd7f9de00000)
  from space 24576K,   0% used [0xfffffd7f9de00000, 0xfffffd7f9de00000, 
0xfffffd7f9f600000)
  to   space 24576K,   0% used [0xfffffd7f9f600000, 0xfffffd7f9f600000, 
0xfffffd7fa0e00000)
 concurrent mark-sweep generation total 1376256K, used 0K 
[0xfffffd7fa0e00000, 0xfffffd7ff4e00000, 0xfffffd7ff4e00000)
 concurrent-mark-sweep perm gen total 21248K, used 12639K 
[0xfffffd7ff4e00000, 0xfffffd7ff62c0000, 0xfffffd7ffa200000)
2010-11-12T11:53:01.376-0500: 360.088: [GC 360.088: [ParNew: 
147456K->7373K(172032K), 0.0093910 secs] 147456K->7373K(1548288K), 
0.0094709 secs] [Times: user=0.03 sys=0.02, real=0.01 secs]



jinfo reports the value of -XX:CMSYoungGenPerWorker=16777216 in both 
scenarios, as well as -XX:ParallelGCThreads=13.  So it's unclear to me 
why the Young Gen would be so small when -Xms and -Xmx are different 
values (Scenario 1).


java -version               
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)


Any insights would be appreciated.

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dde920245681
25-03-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/dde920245681
21-03-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/dde920245681
16-03-2011

WORK AROUND Explicitly set the heap shape.
17-11-2010

EVALUATION There is a dependency between the heap-shape biasing attempted by CMS and the final heap-shaping done by CollectorPolicy(). The two are not communicating optimally, and some tweaks may be needed to make this work as desired. See comments section.
17-11-2010