larval value type and carrier object

[forax at univ-mlv.fr]

yes, 
it can be an Object[] but given you have to construct it before knowing if a pattern fully match or not, it means that there will be at least one allocation for each switch. 

Given that this object is not controlled by the user, having an allocation will muddy the performance model of the pattern matching, using a larval buffer avoid the allocation cost. 

Rémi 

> 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é: Lundi 28 Janvier 2019 23:20:47
> Objet: Re: larval value type and carrier object

> On Jan 26, 2019, at 5:32 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

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

> Yes, that's what I was talking about: The "scratch buffer" contains
> all the state unpacked by the deconstructor. Its type is completely
> unimportant, except that it is agreed upon by the deconstructor
> and its component extraction methods. The client code just sees
> java.lang.Object for the buffer, and never knows what's there.
> As I said, it could be an old-school Object[]. If the deconstructed
> components are all stable with respect to the original object
> (which is the case with immutables) then the scratch buffer can
> be (or need not be) an alias to the same (immutable) object.

> (Isn't it unsafe to make it an Object array, since that is mutable?
> Probably not, since the buffer itself is temporary, and the client
> code walks away with whichever components it picks out of it.
> There are odd exploits possible if the buffer escapes from the
> JVM locals, however.)

> My main point here is that the scratch buffer for the deconstructed
> components can be any old type, including very old types like
> Object[]. Formally, it is an unbounded existential type.

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