Aggressive unboxing of values: status update

[John Rose]

On Nov 10, 2014, at 6:08 PM, Vlad Ureche <vlad.ureche at gmail.com> wrote:

> 2014-11-04 21:35 GMT+01:00 John Rose <john.r.rose at oracle.com>:
> 
>> 
>> The second classic approach is to declare that object identity (for some
>> objects) is indeterminate, and allow the system to make local, decoupled
>> decisions about boxing and unboxing.  (See my blog post "value types in the
>> VM"[2], and the JDK 8 concept of "value-based classes"[3].)  That is the
>> approach Albert is exploring.  This approach is used in Common Lisp (and
>> probably Smalltalk for all I know) to represent numeric value types,
>> instead of giving guarantees about fixnums or interning.  The Common Lisp
>> spec has this interesting glimpse into our possible future[4]:
> 
> 
> Would it make sense to supplement this assumption with a vm warning when
> boxed value identity is exposed? Like printing a message on VM exit: "The
> program you executed uses reference comparisons on boxed values, which are
> known to be non-deterministic. See http://... for more information and use
> -XX:+ErrorOnValueReferenceEquality to trigger an error when such a
> comparison occurs."?

Yes, starting with synchronization on "foo".intern() and Integer.valueOf(42).

Diagnosing invalid use of acmp is harder and will have performance costs,
so might be useful only in a "-Xstrict" mode for testing.

Note that the common idiom "a == b || a.equals(b)" is, practically speaking,
a valid use of acmp for value boxes.  If a or b is a heisenbox, "a == b" might
always be false, causing a call to a.equals(b) which computes the intended
boolean.

— John