RFR: 8147940: Test gc/g1/TestG1TraceEagerReclaimHumongousObjects.java fails

David Lindholm david.lindholm at oracle.com
Tue Jan 26 13:51:35 UTC 2016


Hi,

Please review this patch that fixes 
TestG1TraceEagerReclaimHumongousObjects.java. The test incorrectly 
assumes that there can be no humongous objects if the test doesn't 
allocate such objects. HotSpot allocates a humongous object during class 
loading with the following Java stack trace:

at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1143)
at java.util.zip.ZipFile$Source.<init>(ZipFile.java:962)
at java.util.zip.ZipFile$Source.get(ZipFile.java:932)
at java.util.zip.ZipFile.<init>(ZipFile.java:212)
at java.util.zip.ZipFile.<init>(ZipFile.java:144)
at java.util.jar.JarFile.<init>(JarFile.java:165)
at java.util.jar.JarFile.<init>(JarFile.java:102)
at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:756)
...

... that is when the Central Directory of jfxrt.jar is read into a byte[].

This changed behaviour is because of a change between build 98 and 99, 
probably

8145260: To bring j.u.z.ZipFile's native implementation to Java to 
remove the expensive jni cost and mmap crash risk [2] 
(http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/d85c42d008a9)

Bug: https://bugs.openjdk.java.net/browse/JDK-8147940
Webrev: http://cr.openjdk.java.net/~david/JDK-8147940/webrev.00/


Thanks,
David



More information about the hotspot-gc-dev mailing list