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

[David Lindholm]

Hi Mikael,

Thanks for looking at this.

On 2016-01-27 13:26, Mikael Gerdin wrote:
> 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, 

Thanks!

> 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.

Well, it seems that it tests just that, that the log messages are 
present and well formed. Given the name of the test this is what the 
test should do. There are other tests for verifying the behavior of 
humongous objects.


Thanks,
David

> /Mikael
>
>>
>>
>> Thanks,
>> David
>