larval value type and carrier object

[forax at univ-mlv.fr]

Just for the record, i was talking about the global carrier object, the one in between several match + extract call, the one returned by the call to invokedynamic, not the ones which are a box the return values of a call to a de-constructor/extractor.

For the result of a call to a deconstructor, any value records is Ok, obviously, any records will work but this will create perf issues.

Rémi

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 16 Janvier 2019 18:31:24
> Objet: Re: larval value type and carrier object

> The piece of the puzzle we're looking at, I think,
> is a hidden, scratch multiple value container.
> Brian is using Object[] now, which is very boxy.
> 
> A more apt value container would, of course, have
> primitive (unboxed) fields as well as exactly the
> right number of reference fields; for value types
> it would ideally have unboxed (flat) value fields.
> 
> (At this point everybody is probably thinking
> "yeah you mean a tuple".  Yes, I do, but not a
> user-visible tuple feature, just a low-level,
> logical tuple, sans user syntax and language
> type system.  Call it it a tuple-ish.)
> 
> The tool I'd like to reach for, to improve on the
> boxy Object array, is a BoundMethodHandle.
> That already solves (in a set of compromised
> trade-offs) the problem of storing a small
> bundle of values (the bound MH arguments).
> 
> Instead of a BMH, which is a low-level tuple
> *plus* a chunk of behavior, I'm reaching for
> a copy of the BMH code *minus* the behavior.
> 
> The BMH code (if you look at it) is already
> factored into a super-class which creates
> tuple-ish types, plus a sub-class which adds
> the behavior chunk.  What a coincidence.
> (Mwa-ha-haaaaah!)
> 
> From a MH-centric point of view, the concept
> of a BMH minus behavior is an argument
> bundle.  I am toying with calling this type
> java.lang.invoke.ArgumentList; there are
> many interesting operations possible on it,
> all of which play on the theme of avoiding
> the creation of a boxy Object[] varargs bundle.
> 
> So, when we get tired of Object[], maybe
> the next step is clone BMH and edit to taste.
> 
> So far I've said little about values.  Should
> an ArgumentList be a value type?  Probably,
> or at least it would be a VBC poised for
> migration.
> 
> What role would the larval buffer play?
> Maybe it would be useful in the "guts"
> of the pattern match code.  It doesn't
> need to be visible in the translation
> strategy document, I think, at least
> not across separately compiled units
> and their low-level calling sequences
> for pattern matching.
> 
> — John
> 
> On Jan 15, 2019, at 5:55 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi John, hi Mandy,
>> For de-constructing a matched pattern, we need a carrier object that will
>> temporarily store the captured values,
>> given that jdk.internal.misc.Unsafe has now has the methods
>> uninitializedDefaultValue()/makePrivateBuffer()/finishPrivateBuffer(), i wonder
>> if there is a way to add a method Class<?> createBufferClass(MethodType) that
>> creates a value class with the fields named _0, _1, _2, etc and the types of
>> the fields extracted from the parameter types of the MethodType ?
>> 
>> With the JIT being able to always returns the same class if the MethodType is
>> constant.
>> 
>> Rémi