On Thu, 8 Oct 2020 14:00:11 GMT, Roger Riggs <rri...@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.barr...@oracle.com> >> on hotspot-gc-dev <mailto:hotspot-gc-...@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
