RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Peter Levart]

On 5/31/19 7:24 PM, Roger Riggs wrote:
> Hi Martin,
>
> True, calling System.gc() and then checking for its hoped-for/expected 
> side-effects is the norm.
> But its robustness depends on a combination of gc implementation 
> behavior and
> the particular side-effect expected: allocation, reference processing, 
> etc.
>
> Roger
>
> On 05/30/2019 01:30 PM, Martin Buchholz wrote:
>> If you are calling System.gc() for correctness (e.g. in a test), it 
>> is probably because some sort of finalization is being triggered.  
>> And that happens in some Java thread (e.g. Reference Handler) that 
>> System.gc() has no control over.  So in practice, users need to call 
>> System.gc() and then wait for subsequent reference processing somehow.
>

...there is an internal API 
(java.lang.ref.Reference#waitForReferenceProcessing) and a usage of it 
(java.nio.Bits#reserveMemory) where it is hoped that there is a "happens 
before" between making the newly discovered and cleared Reference(s) 
available for enqueue-ing/processing (in Reference Handler thread) and 
System.gc() returning. In such case, there is a minimum possible latency 
between requesting System.gc() and actual processing of Reference(s) 
such that there is no Thread.sleep() involved. But there's also delay 
based fallback in case the "effort" by System.gc() is not synchronous...

So if some (futre) GC(s) make System.gc() method (partly) asynchronous, 
the above usage will still work, but perhaps with more latency when 
native memory is exhausted.

Regards, Peter