I'm trying to summarize the ideas, this patch provides a way to mark in
the object header if an object is a value object or not. So the JIT or
the interpreter can check at runtime if an object is a value object and
perform optimizations. 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 ? I don't think it's possible because it will require a
check before every ==, or am i missing something ? The other problem is
that a lot of equals of immutable object uses ==,
public boolean equals(Object o) {
if (o == this) {
return true;
}
...
}
so you can't replace == by equals without creating methods that call
itself recursively. I don't see the real interest to have something
checked at runtime for a specific object compared to let say a value
type declared as such with a specific declaration. cheers, Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
