Setting Min and Max Heap Size to the same value affects size of Young Gen

Y. S. Ramakrishna y.s.ramakrishna at oracle.com
Mon Nov 15 10:22:20 PST 2010


Hi Shane --

Yes, the bug exists also in the latest JDK 7 builds. I am looking into it
and filed the following bug to track it:-

  7000125 CMS: Anti-monotone young gen sizing with respect to maximum whole heap size specification

-- ramki

On 11/12/10 13:24, Y. Srinivas Ramakrishna wrote:
> Sounds like a bug to me. I'll check the latest JDK when i get the chance.
> 
> -- ramki
> 
> On 11/12/2010 11:31 AM, Shane Cox wrote:
>> 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.
>>
>>
>>
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
> 
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use


More information about the hotspot-gc-dev mailing list