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
