Forcefully inline reference types

[Remi Forax]

----- Original Message -----
> From: "Julian Waters" <tanksherman27 at gmail.com>
> To: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Sent: Monday, April 25, 2022 5:43:15 AM
> Subject: Re: Forcefully inline reference types

> Possibly something like
> 
> inline Object object = new Object();
> 
> would force any reference type (value and identity objects) it's used on to
> always be inlined/allocated directly where it's instantiated (Eg in a
> scope/stack frame or within another object) instead of initially being
> stored on the heap and only stack allocated/inlined in another object after
> optimizations. Value objects were after all introduced for the purpose of
> allowing HotSpot to inline them more effectively than Escape Analysis
> currently can with regular objects, but to my knowledge this only happens
> when it reaches C2, and it's occurred to me that there hasn't really been
> the option to explicitly inline an object directly at the source level
> rather than wait for HotSpot to do so automatically (the latter also needs
> checks at runtime lest the eager optimization be incorrect), though of
> course this would require new restrictions to be placed on anything with
> the "inline" modifier on it. But we might get extra benefits by doing so
> since we'll know from the start that the particular object is always
> allocated directly where it's created and never supposed to have extra
> space allocated on the heap for it, which lets Lilliput omit GC support
> with that guarantee, but Valhalla might also capitalize on this as well

Hi Julian,
Valhalla value types are flattened very early not when it reaches C2, see [1] for how it works.

It does not work for all existing classes because ==, synchronized, weak refs, etc are specified to work with the idea of having an address in memory.
To have flattening and still be backward compatible as a user you have to opt-in for no identity by declaring the class to be a value class.

> 
> best regards,
> Julian


regards,
Rémi

[1] https://openjdk.java.net/projects/valhalla/design-notes/state-of-valhalla/03-vm-model

> 
> On Sun, Apr 24, 2022 at 11:15 PM Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> Can you elaborate what you mean by “forcefully inline”, as different from
>> the existing mission of Valhalla?
>>
>> > On Apr 24, 2022, at 10:19 AM, Julian Waters <tanksherman27 at gmail.com>
>> wrote:
>> >
>> > Hi all,
>> >
>> > After some discussion with lilliput-dev about the possibility of removing
>> > the entire Mark Word, I'm wondering if being able to forcefully inline
>> > value and identity objects when they're instantiated could have any merit
>> > or benefit to be looked at in Valhalla. The idea came after the
>> realization
>> > that to fully omit the Mark Word the GC bits in the header would also
>> have
>> > to be dealt with, something which cannot be done by simply not having
>> them
>> > in the header given that this may cause GC related performance issues.
>> The
>> > discussed alternative was to not have GC support for certain objects at
>> > all, but that would require it to be able to take advantage of other
>> memory
>> > freeing operations (Eg Popping off a stack frame, being inlined inside
>> > another object to be freed when the containing object is GC'd). To my
>> > knowledge regular objects can already be inlined by HotSpot via Escape
>> > Analysis, would it then be worth discussing to re-use the older "inline"
>> > keyword from Valhalla to allow control over this from the source level as
>> > well? (With the limitation that the object cannot escape its scope, and
>> > only copies of it may be made otherwise, something that may in turn
>> require
>> > semantics for choosing to pass by value or reference)
>> >
>> > There are other issues with locking and identity hashes that relate to
>> > this, but that's probably better discussed back at lilliput-dev if this
>> > happens to be something we can look into
>> >
>> > best regards,
>> > Julian
>>