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

perfdata used is seen as too high on sparc zone with jdk1.9 and causes a test failure

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 8u51, 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Environment:

      solaris sparc 11.1
      Oracle T2 256@3.6/512G Global Zone (slcam264.us.oracle.com)
      Global zone or one of zones in zonepool(ie., slc09qkr)

    • Subcomponent:
      svc
    • Resolved In Build:
      b76
    • CPU:
      sparc
    • OS:
      solaris_11

      Backports

        Description

        Running the test,
        sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.java
        on a solaris machine with lots of memory and cpus (and divided in to zones), this test reports sun.perfdata.used is too close to sun.perfdata.size causing the test to fail.

        This test passes on "lesser" machines.

        I do not know if the failure is related to running in a zone (fails both in GZ and one of the zones in the zonepool), or to the size of the machine (Oracle T2 256@3.6/512G Global Zone).

        This link may be fleeting, but is to a typical jtr file:
        http://java.se.oracle.com/mach5/view/9-dev-test/job/9-dev-tier2-solaris-sparc/99/artifact/JTwork/jdk_test/sun/jvmstat/perfdata/PrologSanity/PrologSizeSanityCheck.jtr/*view*/

        Exception:

        ----------System.err:(13/1079)----------
        java.lang.RuntimeException: jvmstat memory buffer usage approaching size: sun.perfdata.size=32768sun.perfdata.used=31768 : consider increasing PerfDataMemorySize
        at PrologSizeSanityCheck.main(PrologSizeSanityCheck.java:72)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:502)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
        at java.lang.Thread.run(Thread.java:745)
         
        jtr is attached.
        1. JDK-8122944.tar
          9 kB
          Tim Bell

          Issue Links

            Activity

            Hide
            sla Staffan Larsen (Inactive) added a comment -
            The test is failing on machines with lots of CPUs since we create lots of compiler threads and there are 4 perf counters for each compiler thread. This eats memory.

            A simple solution is to just bump the default for PerfDataMemorySize from 32K to 64K - "that should be enough for everyone."
            Show
            sla Staffan Larsen (Inactive) added a comment - The test is failing on machines with lots of CPUs since we create lots of compiler threads and there are 4 perf counters for each compiler thread. This eats memory. A simple solution is to just bump the default for PerfDataMemorySize from 32K to 64K - "that should be enough for everyone."
            Hide
            tbell Tim Bell added a comment -
            % tar -xvf /scratch/JDK-8122944.tar
            tar: blocksize = 18
            x doit.sh, 528 bytes, 2 tape blocks
            x PrologSizeSanityCheck.class, 1877 bytes, 4 tape blocks
            x PrologSizeSanityCheck.java, 3255 bytes, 7 tape blocks

            % export JDK=/scratch/jenkins/workspace/9-dev-tier1-solaris-sparc/build/jdk/

            on slc09qkr (256 CPU, 383G RAM) we get ten times as many threads, and some of those must be compiler threads:

            % truss -f $JDK/bin/java -cp . -XX:+UsePerfData PrologSizeSanityCheck |& grep lwp_create\(\) | wc -l
                 207

            on sca00bny (16 CPU, 32G RAM) we get:

            % truss -f $JDK/bin/java -cp . -XX:+UsePerfData PrologSizeSanityCheck |& grep lwp_create\(\) | wc -l
                  19
            Show
            tbell Tim Bell added a comment - % tar -xvf /scratch/ JDK-8122944 .tar tar: blocksize = 18 x doit.sh, 528 bytes, 2 tape blocks x PrologSizeSanityCheck.class, 1877 bytes, 4 tape blocks x PrologSizeSanityCheck.java, 3255 bytes, 7 tape blocks % export JDK=/scratch/jenkins/workspace/9-dev-tier1-solaris-sparc/build/jdk/ on slc09qkr (256 CPU, 383G RAM) we get ten times as many threads, and some of those must be compiler threads: % truss -f $JDK/bin/java -cp . -XX:+UsePerfData PrologSizeSanityCheck |& grep lwp_create\(\) | wc -l      207 on sca00bny (16 CPU, 32G RAM) we get: % truss -f $JDK/bin/java -cp . -XX:+UsePerfData PrologSizeSanityCheck |& grep lwp_create\(\) | wc -l       19
            Hide
            tbell Tim Bell added a comment -
            Test case from slc09qkr.us.oracle.com
            Show
            tbell Tim Bell added a comment - Test case from slc09qkr.us.oracle.com
            Show
            darcy Joe Darcy added a comment - Review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-July/017717.html
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f160dec9a350
            User: darcy
            Date: 2015-07-28 01:51:39 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f160dec9a350 User: darcy Date: 2015-07-28 01:51:39 +0000
            Hide
            sla Staffan Larsen (Inactive) added a comment -
            JDK-8132876 bumps the default limit to 64K.
            Show
            sla Staffan Larsen (Inactive) added a comment - JDK-8132876 bumps the default limit to 64K.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f160dec9a350
            User: lana
            Date: 2015-08-05 21:01:38 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f160dec9a350 User: lana Date: 2015-08-05 21:01:38 +0000
            Hide
            kshefov Konstantin Shefov added a comment - - edited
            Should be backported to JDK 8. See JDK-8139718.
            Show
            kshefov Konstantin Shefov added a comment - - edited Should be backported to JDK 8. See JDK-8139718.

              People

              • Assignee:
                darcy Joe Darcy
                Reporter:
                ssides Steve Sides
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: