Forcefully inline reference types

[Julian Waters]

Hi Mariell,

It's the former, since Lilliput needs a way to ensure with 100% certainty
that an Object will never require GC support for its lifetime, assigning
OtherClass other = new OtherClass(object) with the pointer to "object" as
an argument would simply be illegal if "OtherClass other" was defined
outside the scope that "object" inhabits, and effectively you could only
copy the contents of that instance into an entirely new one in that case
(I know I did sort of talk about this with you in private, but I feel like
I should put this out here on the mailing list too)

best regards,
Julian

P.S. Seems like you were right with Valhalla owning half of the JDK
projects :P

On Mon, Apr 25, 2022 at 6:05 PM Mariell Hoversholm <
mariell.hoversholm at paf.com> wrote:

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