larval value type and carrier object

[John Rose]

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
>