Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-7000125

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

XMLWordPrintable

    • gc
    • b02
    • b05
    • generic
    • generic
    • Verified

        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.

              ysr Y. Ramakrishna
              ysr Y. Ramakrishna
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: