On 2012-10-16, at 5:14 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
> Frozen/locked is a runtime property, not a type property so it's harder
> that that.
> You have to do a frozen check at the beginning of the method and pray
> that people
> will only use it with frozen object and not a not frozen one because in
> that case, you have to de-optimize.
> Maybe, you can have two versions on the same method, one with the frozen
> semantics and
> one with the boxed one (this is what I have done in JDart).
I'm still coming up to speed on this, but I thought that the entire point of
having value objects
is so that we would have a non-standard interface for all methods dealing with
value objects.
"Complex", boxed, is received as a single pointer to an object with headers and
fields.
"Complex", unboxed, is received as a pair of double. The "frozen check" is
punted to the caller,
who in turn may have punted it to his caller, etc, potentially removing the
need for all tests.
Or did I read this wrong?
The only place I see a need for a frozen check is when we are interoperating
with legacy code
that is not playing the frozen-object game, and that we want to run with
complete legacy compatibility.
In the case, the slow-and-boxed path also includes a frozen check -- if frozen,
unbox the object,
and head for the fast path, otherwise, stay slow.
>From the notes (value-obj.txt) I see:
38 - the reference returned from the (unsafe) marking primitive must be used
for all future accesses
39 - any previous references (including the one passed to the marking
primitive) must be unused
40 - in practice, this means you must mark an object locked immediately after
constructing it
So, allocation of a value-object becomes something along the lines of
new java/lang/Integer
dup
iload ...
invokespecial java/lang/Integer.<init>(I)V
markingPrimitive
But we can't rely on this, hence it is not a true type property. But we could
make it be as-if.
I think I have to assume some sort of a marker class ("implements
PermanentlyLockable").
Then in bytecode version N+1, the verifier enforces this for all types
implementing PL, and
all methods trucking in PL-implementing objects will by default generated
unboxed entrypoints.
Except when dealing with legacy code, it's as good as a type.
For legacy code, I think we have options. Simplest is just to box at the
boundaries, with lazy
compilation of boxed versions of PL-handling methods in modern bytecodes. I'm
trying to decide
if we can do better with flow analysis; I think it has to be non-publishing in
the PL types, in addition
to the other properties.
David
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
