Forcefully inline reference types

[Julian Waters]

Hi Remi,

I think there might be a small misunderstanding, I was referring to simply
giving language level control over the inlining of objects (like what the
JVM can already do to identity objects with Escape Analysis), not the
flattening of value objects to bare values for denser storage

Eg comparing

inline SomeObject object;

public MyClass() {
    this.object = new SomeObject();
}

to

SomeObject object;

public MyClass() {
    this.object = new SomeObject();
}

would yield the MyClass object memory layout of

----------------------------------------
MyClass Object
----------------------------------------
object = SomeObject instance
----------------------------------------

for the former and

-----------------------------------------
MyClass Object
-----------------------------------------
object = SomeObject reference
-----------------------------------------

for the latter

best regards,
Julian

On Fri, Apr 29, 2022 at 3:18 PM Remi Forax <forax at univ-mlv.fr> wrote:

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