Forcefully inline reference types

[Julian Waters]

Also, it seems https://openjdk.java.net/jeps/8277163 is providing
conflicting information with
https://openjdk.java.net/projects/valhalla/design-notes/state-of-valhalla/03-vm-model
?

>From the JEP:
Value objects in HotSpot are encoded as follows:

   -

   In fields and arrays, value objects are encoded as regular heap objects.
   -

   In the interpreter and C1, value objects on the stack are also encoded
   as regular heap objects.
   -

   In C2, value objects on the stack are typically scalarized when stored
   or passed with concrete value class types. Scalarization effectively
   encodes each field as a separate variable, with an additional variable
   encoding null; no heap allocation is needed. Methods with
   value-class-typed parameters support both a pointer-based entry point (for
   interpreter and C1 calls) and a scalarized entry point (for C2-to-C2
   calls). Value objects are allocated on the heap when they need to be viewed
   as values of a supertype of the value class, or when stored in fields or
   arrays.




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