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

[Mandy Chung]

On Sun, 4 Oct 2020 03:59:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> 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.

Can you add a unit test in `test/jdk/java/lang/ref` that serves as a basic API test for this new `refersTo` API without
depending the WhiteBox API?     test/hotspot/jtreg/gc` test serves as a more white-boxed type and comprehensive test.

src/java.base/share/classes/java/lang/ref/Reference.java line 361:

> 359:
> 360:     /* Type-erased implementation of refersTo(). */
> 361:     native boolean refersTo0(Object o);

Is there any reason why it can't use the parameter type like `refersTo0(T o)`?  Same for `PhantomReference::refersTo0(T
o)`

src/hotspot/share/include/jvm.h line 334:

> 332:  */
> 333: JNIEXPORT jboolean JNICALL
> 334: JVM_PhantomReferenceRefersTo(JNIEnv *env, jobject ref, jobject o);

Instead of a separate `PhantomReference::refersTo0` native method (and new PhantomReference.c), an alternative approach
could be to detect if `ref` is an instance of `PhantomReference`  or other `Reference` and get the referent accordingly.

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

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