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

[Mikael Gerdin]

Hi David,

On 2016-01-26 14:51, David Lindholm wrote:
> 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/

The change seems ok, but I wonder what the test actually tests now that 
it only verifies that the log messages are present, previously it at 
least verified that "Humongous total" was 0 when it was expected to be 0.

/Mikael

>
>
> Thanks,
> David