Testing no memory leak occurs via references

[Thomas Schatzl]

Hi,

On 03.03.23 19:02, Aleksei Ivanov wrote:
 > Hello,
 >
 > In clientlibs, there's occasionally a need to verify an object isn't
 > leaked. For this purpose, WeakReference or PhantomReference is used.
 >
 > Then, we need to make the reference object be cleared, so a GC cycle
 > need to be triggered. The common approach is generating
 > OutOfMemoryError, catching it and verifying whether the reference is
 > cleared.
 >
 > Some tests use a utility method regtesthelpers/Util.generateOOME [1].
 >
 > For example, these tests follow the above approach:
 > 
https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/border/TestTitledBorderLeak.java
 > 
https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 >
 >
 > The AwtListGarbageCollectionTest.java test started to fail pretty often
 > in the end of January 2023.
 >
 > I followed a piece of advice provided in a JBS comment for JDK-8300727
 > [2] and replaced generating OOME with a simple call to System.gc() along
 > with adding a loop for re-trying.
 >
 > The specification for System.gc() [3] mentions that this call can be
 > ignored, which started a discussion in the PR #12594 [4] that
 > System.gc() should not be used, at the very least without generating
 > OOME in addition to invoking System.gc().
 >
 > At the same time, many tests for Reference objects, such as
 > ReferenceEnqueue.java [5] and PhantomReferentClearing.java [6], rely
 > solely on System.gc.
 >
 >
 > What would be your recommendation? Are there best practices in core-libs
 > and hotspot for testing for memory leaks that clientlibs should follow?
 >
For tests, the Whitebox methods allow you to specify the exact GC you 
want to have with a guarantee that it will be executed (in addition to 
potentially others caused naturally by the application!), i.e. 
minor/major gc, and specific to collectors, start concurrent gcs etc.

E.g. test/hotspot/jtreg/gc/whitebox/TestWBGC.java gives an example how 
to execute young gcs.

It may not be a comprehensive API to test all kinds of GCs, but it fits 
the use cases we need so far.

I recommend to not use OOME for anything unless in extremely specific 
situations (test OOME is triggered or something). At/after OOME the VM 
is in a very precarious state that can give unexpected VM bailouts.

Thanks,
   Thomas