Testing no memory leak occurs via references

[David Holmes]

On 7/03/2023 8:16 pm, Kim Barrett wrote:
>> On Mar 6, 2023, at 10:11 AM, Aleksei Ivanov <alexey.ivanov at oracle.com> wrote:
>>
>> On 06/03/2023 13:51, Albert Yang wrote:
>>> Upon a cursory inspection of ForceGC.java, it seems that the fundamental logic involves waiting for a certain duration and relying on chance. However, I am of the opinion that utilizing the WhiteBox API can provide greater determinism and potentially strengthen some of the assertions.
>>
>> Yes, it calls System.gc in a loop and waits for a reference to become cleared.
> 
> WhiteBox.fullGC is better.

But is awkward to use within tests.

Makes me wonder whether System.gc() should do whatever WhiteBox.fullGC() 
actually does?

David
-----

> System.gc may not do a full GC; consider, for example, G1 with
> -XX:+ExplicitGCInvokesConcurrent.
> 
> Because of potential cross-generational j.l.r.Reference and referent, one
> invocation might not clear a Reference that would be cleared by a full GC, and
> might in fact require many iterations.
> 
> Also, because of SATB requirements, G1 with -XX:+ExplicitGCInvokesConcurrent
> might never clear a Reference if it is being checked for being cleared in the
> traditional way (by ref.get() == null) rather than by using the newer
> ref.refersTo(null).
> 
> WhiteBox.fullGC deals with both of those, and there's no need for looping.
> The loops in functions like ForceGC are to deal with those kinds of issues.
> And waiting for clearing is completely pointless.  A given GC invocation will
> either clear or not, and there's not a delay afterward.
> 
> The ZGC equivalent of the second can still be a problem. Checking for a
> cleared Reference really should be done using Reference.refersTo.
> 
>