The last miles

[forax at univ-mlv.fr]

> From: "daniel smith" <daniel.smith at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Monday, August 21, 2023 9:12:03 PM
> Subject: Re: The last miles

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

inside <vnew>, yes, but at the end of <vnew> if it goes back into the interpreter, the return value will be buffered. 

I do not think it is obvious if there will be performance regression or not until the new scheme is implemented and tested. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230821/4f7c5e97/attachment-0001.htm>