[mvt] RFR - add support for q-types in lambda forms

[Paul Sandoz]

> On 5 Jun 2017, at 13:50, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 
> On 05/06/17 19:44, Remi Forax wrote:
>> Hi Paul,
>> John will say it better than me but the plan as far as i've understood is to just add a new Q basic type,
>> represented by __Value in the signature as Karen said.
> Yep - that's what the lambda form patch I've sent does - it adds a new basic type and InvokeBytecodeGenerator has been expanded to handle the new basic type Q in LF signatures.
> 
> Species classes should have an additional set of methods for binding to Q arguments. But I think these need to be spun in the bytecode, since I don't think if you name j.l.__Value in a method signature you'll get what you want at the bytecode level.
> 

What should be the signature of the Species fields bound to one or more values?

Paul.

(Separately Species classes themselves seem good candidates to be value classes, which i think we could do since we can spin ‘em up.)

> Maurizio
>> 
>> Rémi
>> 
>> ----- Mail original -----
>>> De: "Paul Sandoz" <paul.sandoz at oracle.com>
>>> À: "Karen Kinnear" <karen.kinnear at oracle.com>
>>> Cc: valhalla-dev at openjdk.java.net
>>> Envoyé: Lundi 5 Juin 2017 20:20:21
>>> Objet: Re: [mvt] RFR - add support for q-types in lambda forms
>>> One thing that concerns me about BMHs and Species is the possible combinatorial
>>> explosion if we have to create specific Species classes to hold values. At the
>>> moment the method handle internals operate on five basic types (L, I, J, F and
>>> D).
>>> 
>>> What should the type of a Species field that holds a value augment which:
>>> 
>>> 1) avoids boxing to Object; and
>>> 
>>> 2) avoids a possible combinatorial explosion.
>>> 
>>> ?
>>> 
>>> Is there an intermediate carrier type we can use has less baggage than Object?
>>> 
>>> Paul.