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 <fo...@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
