Hi Kim,
On 8/04/2020 10:25 am, Kim Barrett wrote:
[Note review on both core-libs and hotspot-gc-dev lists; try not to lose
either when replying.]
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.
This causes a slight conflict with the documentation for get() which states:
"Because the referent of a phantom reference is always inaccessible ..."
when the new method obviously accesses it.
The new function uses a native method whose implementation is in the
VM so it can use the Access API. It is the intent that this function
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.
I assume such intrinsification is intended for JDK 15 as well though, as
end users may well rush to change their code!
CR:
https://bugs.openjdk.java.net/browse/JDK-8188055
https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR)
In the specification:
* @param obj is the object to compare with the referenced object, or
* {@code null}.
First delete "is", the commone style for @param is just to say "the xxx"
or "a yyy".
Second I suggest:
s/the referenced object/this reference object's referent/
In the apinote:
* collection cycle. {@link #refersTo(Object) refersTo} can be used to
I suggest:
* collection cycle. The {@link #refersTo(Object) refersTo} method can
be used to
so we don't start a sentence with a lower-case code-font word.
Also a query in the apinote:
* This method returns a strong reference to the referent. This may cause
* the garbage collector to treat it as strongly reachable until some later
Surely if the method returns a strong reference then the GC _will_ treat
it as strongly reachable, not "may" ?
Webrev:
https://cr.openjdk.java.net/~kbarrett/8188055/open.04/
Code changes look good. No comment on the test - I'll leave it to others
to analyse that.
Thanks,
David
-----
Testing:
mach5 tier1
Locally (linux-x64) verified the new test passes with various garbage
collectors.
