[mvt] RFR - add support for q-types in lambda forms
maurizio.cimadamore at oracle.com
Mon Jun 5 23:12:47 UTC 2017
On 05/06/17 23:18, Paul Sandoz wrote:
>> 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?
That's what we use in the signature of generated code corresponding to
value-bearing lambda forms.
> (Separately Species classes themselves seem good candidates to be value classes, which i think we could do since we can spin ‘em up.)
>>> ----- 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
>>>> 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?
More information about the valhalla-dev