Testing no memory leak occurs via references
David Holmes
david.holmes at oracle.com
Wed Mar 8 09:36:02 UTC 2023
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.
>
>
More information about the hotspot-gc-dev
mailing list