Forcefully inline reference types

[Mariell Hoversholm]

Hi Julian,

I'm not fully sure I understand what you mean by inlining the instantiation
point.
Do you want the given `object` to be allocated on the stack when it is
"inlined", or do you want it to act somewhat like this?:

    inline Object object = new Object();
    new OtherClass(object);
    OtherClass(Object object) {}

    // being the same as:
    Supplier<Object> inlineObject = Object::new;
    new OtherClass(inlineObject);
    /* synthetic? */ OtherClass(Supplier<Object> $object) {
        this($object.get());
    }
    OtherClass(Object object) {}

i.e. letting it be instantiated at each point of use?

In either case, I do not see this as a beneficial change as a consumer of
the language. Should it act as a stack-allocation request, it raises the
question of how `new OtherClass(new Object())` would behave, and if it
could be inline. Should it act as the second example, it includes implicit
behaviour which in my eyes is better represented through the supplier
example.

I may simply be missing the entire point altogether, too, in which case I
apologise and would love to learn what you mean.

Cheers,
Mariell

On Mon, 25 Apr 2022 at 05:44, Julian Waters <tanksherman27 at gmail.com> wrote:

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