Testing no memory leak occurs via references

[John Hendrikx]

On 08/03/2023 10:36, David Holmes wrote:
> 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?

Would this be available to test code outside the JDK?

Outside the JDK, there also exists a need to ask the system if a 
reference can be cleared. This is usually part of test code to see if no 
memory is being leaked unexpectedly. System.gc() is currently our only 
hope to perform such tests, but it is clear it isn't intended for that 
purpose.

Perhaps there should be a more targetted solution; the intent isn't to 
run a GC (although that may be necessary depending on the 
implementation) but to test if a reference can be cleared. 
Implementations that can't or won't clear references could throw an 
exception to indicate this kind of test would not work with the current 
configuration.

--John


>
>> 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.
>>
>>