JDK-8122944 : perfdata used is seen as too high on sparc zone with jdk1.9 and causes a test failure
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 8u51,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_11
  • CPU: sparc
  • Submitted: 2015-06-17
  • Updated: 2016-04-27
  • Resolved: 2015-07-28
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 8 JDK 9
8u101Fixed 9 b76Fixed
Related Reports
Relates :  
JDK-8081734 - ConcurrentHashMap/ConcurrentAssociateTest.java, times out 90% of time on sparc with 256 cpu.
Relates :  
JDK-8132876 - Increase PerfDataMemorySize to 64K
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.
Comments
Should be backported to JDK 8. See JDK-8139718.
19-10-2015
JDK-8132876 bumps the default limit to 64K.
03-08-2015
Review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-July/017717.html
28-07-2015
Test case from slc09qkr.us.oracle.com
17-06-2015
% 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
17-06-2015
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."
17-06-2015