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

[Roger Riggs]

On Tue, 6 Oct 2020 00:19:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - improve refersTo0 descriptions
>>  - basic functional test
>>  - change referent access
>>  - expand test
>>  - remove CMS comment
>
> 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$>.
>

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

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