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

[Kim Barrett]

> On Oct 5, 2020, at 9:15 PM, Roger Riggs <rriggs at openjdk.java.net> wrote:
> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 66:
> 
>> 64:     @Override
>> 65:     native final boolean refersTo0(Object o);
>> 66:
> 
> How does the existence of this method help future intrinsification?
> If it was called somewhere it would be clearer.
> Perhaps a comment now or later would help explain its function.

public final refersTo(T o) calls refersTo0(o)

We have package private:
      native boolean Reference::refersTo0(Object)
final native boolean PhantomReference::refersTo0(Object)

The reason for this split has to do with details in the VM support, in
particular C2 intrinsification.

For the native method support we don't need this split.  The original
version from back in April just had a single native method in Reference. (It
did have native refersTo0, but that was my not realizing native methods
could have a parameterized type that would get type-erased automatically;
see response to Mandy.)  That native method performed a runtime check on the
ReferenceType of the reference's klass to determine what to do. (See below.)

Phantom references need to be treated differently from stronger "weak"
reference types, because phantom references are weaker than finalization, so
might not be cleared when a stronger reference to the same object is
cleared.  For collectors with STW reference processing this doesn't make
much difference (the referent is either cleared or not), but making this
distinction correctly is necessary for concurrent reference processing.

The Access API that provides the interface to the GC has support for
"unknown" referent accesses that perform a runtime lookup.  This is
supported in C++ code, but not in the various Java code processors
(interpreter and compilers).  We didn't previously need to support that case
for Java because the only place where it mattered was accessing the referent
of a PhantomReference, and that is blocked by PhantomReference::get that
always returns null.

For refersTo the intent is to have the interpreter and C1 use the native
method, but have C2 have special knowledge for it. We could add support for
the "unknown" reference type to C2, but that's a substantial amount of work,
and only useful for this one place.  Or we can take the same approach as for
get(), i.e. have a second method on PhantomReference so that calls that can
select the appropriate method at compile time (usually the case) can have
distinct intrinsics for the two cases.

By having these intrinsifiable native methods be package private we can have
the public refersTo API function be final, while also preventing any further
overrides by classes not in the same package.

I'll try to come up with some commentary.