Failure in LoaderLeakTest

[tajila]

It appears that we are hanging while running the loader leak test.

Agent error: java.lang.Exception: Agent 6 timed out with a timeout of 960 seconds; check console log for any additional details    

java/lang/annotation/LoaderLeakTest.java.LoaderLeakTest

[tajila]

@hangshao0 Can you please take a look at this. Just need to determine if its JVM issue or something else.

[hangshao0]

There is an infinite loop in the test. It expects a weak reference to be cleared by System.gc(). It is not cleared and we never get out of the loop, so the test fails on timeout.

https://github.com/ibmruntimes/openj9-openjdk-jdk17/blob/c9d6bc450c26f4ea6132e1ebed6b60d04a47f0aa/test/jdk/java/lang/annotation/LoaderLeakTest.java#L90-L93

I guess the GC team needs to take a look.

[tajila]

@dmitripivkine does calling System.gc() provide any guarantees about weak references being cleared?

[dmitripivkine]

In general calling System.gc() in the loop multiple times (and left time between for Finalization threads to run) must clean all weak referenced objects available for it (in my practice calling System.gc() 3-4 times with 1s delay between is enough). However Weak Reference can not be cleared if referent has a strong root. Also weak referencing is applicable to objects referenced from referent slot. All other objects slots in Weak Reference object behaves as regular (strong) reference.

If we do have system core it is possible to locate Weak Refs in question and check is referent strong referenced. So if you provide system core I can take a look.

[dmitripivkine]

Also you can try -Xint. JIT might put reference to referent to O-slot as optimization so create a strong root.
There is an issue for reference #9969
Looks like there is more precise option to try -Xjit:enableAggressiveLiveness

[dmitripivkine]

Also looking to the test source - there is an extra possibility: GC provides extra liveness for classloader object / each class object for class in this classloader if there is instance of class is alive (strong referenced) in the heap (for any class in this classloader). If it is a case classloader can not be unloaded and stays alive, all classes are marked as a strong roots.

[hangshao0]

Looks like there is more precise option to try -Xjit:enableAggressiveLiveness

The timeout goes away and test successfully passed with -Xjit:enableAggressiveLiveness.

[dmitripivkine]

So looks like there is a JIT feature to make test fail. Yes, it makes test incompatible but itself it just introduces different (not wrong) behaviour for JVM. I believe JIT experts can provide a proper conclusion
@0xdaryl FYI

[pshipton]

The test was backported to jdk11 in 11.0.19. Created adoptium/aqa-tests#4357 to exclude it there.