> On Mar 6, 2023, at 10:11 AM, Aleksei Ivanov <alexey.iva...@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. 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.
signature.asc
Description: Message signed with OpenPGP
