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

[Gil Tene]

Lifting out of response from the JIRA issue:

I always worry when proposing a change to an existing invariant, and
PhantomReference currently carries the stated and specified behavior
of "the referent of a phantom reference is always inaccessible".

I can imagine quite a few forms of gaining new information I do not otherwise
have access to by using PhantomReference::RefersTo if it allowed me to examine
the current referent of a phantom reference and test to see if it is (a) null or (b) a
specific object I have a reference to. Both of those would provide me with information
that is impossible for me to get according to current specifications. With that newly
available information one can come up with all sorts of nice things to do... Think in
terms of "side-channel" as an example of the sort of thinking black hats can apply
to this new knowledge, but the potential attacks are not limited to side-channels.

While it will be "obviously safe" to have Reference:RefersTo(obj) provide the same
information that (Reference.get() == obj) would, providing more information than
that would be a change to the specified behavior of Reference types, which we
should be extra paranoid about. Since PhantomReference::get returns null by
definition, we should remain consistent with that in PhantomReference::refersTo

> On Apr 8, 2020, at 7:56 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> 
> Hi Gil,
> 
> Lifting out my reply to you from the JIRA issue:
> 
> In terms of breaking existing logic, I am not worried. This is a new API, that nobody is using yet. People that write new code that uses it, will have to pay attention that they are doing the right thing. We are still not exposing the phantom referent with this change. In terms of security, you can only use this API to figure out what the referent is, if you already have access to it. So that isn't really helpful for building exploits. What it could do is allow you to check which one of N objects that you already have access to is the one referred to from the PhantomReference. But in terms of security, you could also have just guessed that without this API, as you already have full access to the objects. Sounds like a classic case of "I have an exploit. Given a compromised system... X". Or have I missed something?
> 
> Thanks,
> /Erik
> 
> On 2020-04-08 16:25, Gil Tene wrote:
>> A very welcome change overall. However, I have concerns about
>> the semantic change to the PhantomReference specification. I propose
>> that PhantomReference semantics remain unchanged, and that
>> PhantomReference:RefersTo should return true only for null.
>> 
>> See more in comment at https://bugs.openjdk.java.net/browse/JDK-8188055?focusedCommentId=14329319&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14329319
>> 
>>> On Apr 7, 2020, at 5:25 PM, Kim Barrett <kim.barrett at oracle.com> 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.
>>> 
>>> 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.
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8188055
>>> https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR)
>>> 
>>> Webrev:
>>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/
>>> 
>>> Testing:
>>> mach5 tier1
>>> 
>>> Locally (linux-x64) verified the new test passes with various garbage
>>> collectors.