hg: mlvm/mlvm/hotspot: value-obj: first cut

[Remi Forax]

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