The last miles

[Brian Goetz]

This is a good thought; we split the initialization protocol and its a fair question to ask whether we can go back to a lump.  

In this case, I suspect John is about to say “Please let’s not give the verifier any more jobs to do.”  


> On Jul 13, 2023, at 3:39 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi all,
> if we take a step back and think about how value types are currently implemented,
> a good retconing is that value classes are classical classes that behave slightly differently at runtime when they are JIT optimized
> and if an optimization has to be done before JIT time (class layout by example) then we use side channels (Preload attribute and field attribute) so the information needed for the optimizations are available before JIT time. 
> 
> There is one area where this is not true, class instantitation, for class instantiation, currently the Java compiler transforms the bytecode,
> this has two major disatvantages, we need two new bytecodes, a special factory method <new> and we do not support direct instantitation e.g. new Integer().
> I wonder if we can not revisit that now and solve this last miles issue.
> 
> I believe that the important property for value class instantitation that "this" should not escape the constructor and that instead of having the compiler to rewrite the bytecode, the constructor can be a classical <init> method, the verifier will check that "this" does not escape, the JIT can not delay the initialization of the value type before its uses (this is already true because all fields are final) so at runtime no code can see a half baked value class instance.
> 
> Obviously, I'm not a VM implementor and I barely know how things really work, so it might be a fantasy, but I think it's one that is worth trying to make a reality.
> 
> Rémi