On Oct 14, 2012, at 2:25 PM, Remi Forax wrote:
> A value object is a true immutable object so the
> JIT can constant fold field access or merge redundant access even if
> there is method call between them but for that the JIT has to insert a
> check to know if the object is frozen (definitively better than 'locked'
> IMO) or not. Things are less clear for me when you have operation like
> ==, does it means that a frozen object has not the same semantics as a
> not frozen one ?
The reference semantics of a frozen/locked/immutable object are (must be) a
subset of the full reference semantics of a normal Java object.
The essential feature of a locked object, I think, is that the JVM is free to
rebox it at any time. (Maybe there is a restricted set of "times" that could
make sense, but I'm thinking "between any two bytecodes".)
Once you grant the JVM the right to rebox at any time, you get indeterminate
behavior on operations like this:
Complex x = Complex.valueOf(0, 1);
synchronized (x) { } // cannot distinguish from synchronized (x.clone()) { }
System.identityHashCode(x); // cannot distinguish from
System.identityHashCode(x.clone())
assert(x == x); // cannot distinguish (??) from (x == x.clone())
Object y = x;
assert(y == x); // cf. (y == x.clone())
Object y2 = y;
assert(y2 == y); // probably true, but how do you tell the view type from the
bytecodes?
synchronized (y) { }
System.identityHashCode(y);
ArrayList<Complex> xs = ...;
xs.set(0, x);
Complex z = xs.get(0);
assert(z == x);
...
This right-to-rebox also means that the JVM can throw away escape analysis for
such types, since any escaping can be cloned first. The end result is that
nearly all immutable values (of fixed small size) can be allocated to
registers. This (crucially) includes values passed into and returned out of
non-inlined methods. This is the basis for a number of urgently useful things,
beyond Complex.
My goal here is to find a set of design rules under which the indeterminacy (a)
doesn't matter, (b) can be diagnosed with an exception, and/or (c) can be
overwritten by an uplevel operation (like Object.equals). That's what this is
about:
https://blogs.oracle.com/jrose/entry/value_types_in_the_vm
Mega-extra points for retrofitting to existing bytecodes and behaviors in
rt.jar etc.
— John_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
