Review Request JDK-8201793: (ref) Reference object should not support cloning

Paul Sandoz paul.sandoz at oracle.com
Thu Apr 26 19:35:24 UTC 2018


Hi Mandy,

This looks reasonable. I suspect external subtypes of the j.l.ref types are extremely rare (grep code reports no derived types) and of those it would likely be even rarer for those subtypes to implement Cloneable, and for that functionality to operate reliably.

Paul. 

> On Apr 26, 2018, at 7:16 AM, mandy chung <mandy.chung at oracle.com> wrote:
> 
> The semantics of cloning a Reference object is not clearly defined. In addition, it is questionable whether it can be meaningfully supported in particular with concurrent reference processing.
> 
> The reachability state of a Reference object may change during GC reference processing. The referent may have been cleared when it reaches its reachability state. In addition, it may be enqueued or pending for enqueuing. Cloning a Reference object with a referent that is unreachable but not yet cleared might mean to resurrect the referent. A cloned enqueued Reference object will never be enqueued.  A Reference object cannot be meaningfully cloned.
> 
> We propose Reference::clone to throw CloneNotSupportedException.  To clone a Reference object, it should create a new instance via its constructor.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8202260
> 
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8201793/webrev.00/
> 
> Mandy



More information about the core-libs-dev mailing list