RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

[Per Liden]

On Thu, 8 Oct 2020 14:00:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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.
>
> Hi Kim,
> 
> At what point would the @IntrinsicCandidate annotation be added to the
> refersTo0 methods?
> it would be useful documentation even if it is not needed for the mechanism.
> 
> Thanks for the explanation, Roger
> 
> 
> On 10/8/20 3:58 AM, mlbridge[bot] wrote:
>>
>> /Mailing list message from Kim Barrett <mailto:kim.barrett at oracle.com>
>> on hotspot-gc-dev <mailto:hotspot-gc-dev at openjdk.java.net>:/
>>
>>     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
>>         <https://urldefense.com/v3/__https://github.com/override__;!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8nJgqULa$>
>>         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.
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/498*issuecomment-705400053__;Iw!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8m3Tmikx$>,
>> or unsubscribe
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAIRSVBIN2XWNEM3ILBOLI3SJVWI3ANCNFSM4SDN74VA__;!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8skFFiqO$>.
>>

> In the places where expectNotCleared is used, the expected value is unavailable; the associated testObjectN variable
> has been nulled.

Ah, true.

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

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