On Aug 21, 2023, at 11:39 AM, [email protected] wrote: 1) A larval value object is an identity object. This means, in the hand-off between the <init> method and the caller, the object must be heap allocated: the caller and the <init> method need an agreed-upon memory location where state will be set up.
I can see this being optimized away if the <init> method can be inlined. But if not (e.g., the constructor logic is sufficiently complex/large), that's a new cost for value object creation: every 'new' needs a heap allocation. (For <vnew>, we are able to optimize the return value calling convention without needing inlining.) A larval value object is a value object with the larval state to "on", it's not an identity object. At the end of the call of <init>, the larval state is set to "off". The larval bit controls if putfield is allowed or not. I mean it is an "identity object" in the sense that it must live at a canonical, mutable memory location. E.g., you can't scalarize it across calls, you have to pass it by reference. But, agreed, "larval object" and "identity object" are distinct concepts. It's just that both of them depend on some sort of "identity" capability. (Separately, we can dig further into the question of whether you actually need runtime flags to detect this state change, or can leave it to verification. That's my point (5).) In the interpreter, a larval value object is buffered, so there is an heap allocation. But in JITed code, if everything is inlined Exactly: "if everything is inlined". My point (1) is that if everything *is not* inlined, there are allocations that <vnew> was able to optimize away.
