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