RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]

Roger Riggs rriggs at openjdk.org
Thu Jun 30 20:38:40 UTC 2022

On Thu, 30 Jun 2022 18:24:14 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/ForceGC.java line 70:
>>> 68:                 // But it is fine.  For most cases, the 1st GC is sufficient
>>> 69:                 // to trigger and complete the cleanup.
>>> 70:                 queue.remove(200L);
>> If `remove()` returns a non-null value, then it is safe to break out of the loop.
>> The GC has cleared the ref. And the final `getAsBoolean()` below will return the condition.
> I'm not sure if all unused object will be collected in one GC call always.  The gc() specification says "When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all unused objects. ... There is also no guarantee that this effort will determine the change of reachability in any particular number of objects, or that any particular number of {@link java.lang.ref.Reference Reference} objects will be cleared and enqueued."  But from the spec, I did not get a clear answer for the question.
> If the `booleanSupplier` object could be cleared in a collection other than the `ref` collection, the current code may be safer.

True, knowing when GC is 'done' is not deterministic except for a specify Reference to a specific object.
System.gc is just a request, the checking for an object can more quickly exit the loop.
The code is as is, and already commented, might wait an extra cycle, but only in the case of a race between the requested predicate and the object being reclaimed.  Ok as it.


PR: https://git.openjdk.org/jdk/pull/8979

More information about the security-dev mailing list