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

Paul Sandoz paul.sandoz at oracle.com
Mon Jun 5 22:18:33 UTC 2017

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


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

More information about the valhalla-dev mailing list