Details
Bug
P4
Description
The documentation for PhantomReference says
"... the referent of a phantom reference may not be retrieved: The
{@code get} method of a phantom reference always returns {@code null}."
and the documentation for get() says
"Returns this reference object's referent. Because the referent of
a phantom reference is always inaccessible, this method always
returns {@code null}."
In other words, those do not merely say that PhantomReference.get() returns null. Rather, they say there is no access path to the referent and, as a consequence, get() returns null.
However, the current implementation allows access to the referent of a PhantomReference by either reflection (ultimately, Unsafe_GetObject or Unsafe_GetObjectVolatile) or JNI (jni_GetObjectField). Neither of these access paths does anything to recognize the field being accessed is a PhantomReference referent and block the access.
Note that these accessors already need to recognize referent accesses in order to provide the read barrier needed by G1.
"... the referent of a phantom reference may not be retrieved: The
{@code get} method of a phantom reference always returns {@code null}."
and the documentation for get() says
"Returns this reference object's referent. Because the referent of
a phantom reference is always inaccessible, this method always
returns {@code null}."
In other words, those do not merely say that PhantomReference.get() returns null. Rather, they say there is no access path to the referent and, as a consequence, get() returns null.
However, the current implementation allows access to the referent of a PhantomReference by either reflection (ultimately, Unsafe_GetObject or Unsafe_GetObjectVolatile) or JNI (jni_GetObjectField). Neither of these access paths does anything to recognize the field being accessed is a PhantomReference referent and block the access.
Note that these accessors already need to recognize referent accesses in order to provide the read barrier needed by G1.