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
