The last miles

[Dan Smith]

On Aug 21, 2023, at 11:39 AM, forax at univ-mlv.fr 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230821/e5848f3b/attachment.htm>