Forcefully inline reference types

[Julian Waters]

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

best regards,
Julian

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