RFR: 8188055: (ref) Add Reference::refersTo predicate

Kim Barrett kbarrett at openjdk.java.net
Mon Oct 5 08:31:49 UTC 2020


Finally returning to this review that was started in April 2020.  I've
recast it as a github PR.  I think the security concern raised by Gil
has been adequately answered.
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html

Please review a new function: java.lang.ref.Reference.refersTo.

This function is needed to test the referent of a Reference object without
artificially extending the lifetime of the referent object, as may happen
when calling Reference.get.  Some garbage collectors require extending the
lifetime of a weak referent when accessed, in order to maintain collector
invariants.  Lifetime extension may occur with any collector when the
Reference is a SoftReference, as calling get indicates recent access.  This
new function also allows testing the referent of a PhantomReference, which
can't be accessed by calling get.

The new function uses native methods whose implementations are in the VM so
they can use the Access API.  It is the intent that these methods will be
intrinsified by optimizing compilers like C2 or graal, but that hasn't been
implemented yet.  Bear that in mind before rushing off to change existing
uses of Reference.get.

There are two native methods involved, one in Reference and an override in
PhantomReference, both package private in java.lang.ref. The reason for this
split is to simplify the intrinsification. This is a change from the version
from April 2020; that version had a single native method in Reference,
implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
However, adding support for that category in the compilers adds significant
implementation effort and complexity. Splitting avoids that complexity.

Testing:
mach5 tier1
Locally (linux-x64) verified the new test passes with various garbage collectors.

-------------

Commit messages:
 - new function

Changes: https://git.openjdk.java.net/jdk/pull/498/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8188055
  Stats: 389 lines in 8 files changed: 387 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/498/head:pull/498

PR: https://git.openjdk.java.net/jdk/pull/498


More information about the core-libs-dev mailing list