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

[Maurizio Cimadamore]

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.

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.
>>
>>> On 5 Jun 2017, at 10:56, Karen Kinnear <karen.kinnear at oracle.com> wrote:
>>>
>>> The top value wrapper type today is sort of a marker type - i.e. you can not
>>> instantiate one, and in MVT
>>> you can currently use it in either a method signature or for vreturn.
>>>
>>> If you have other required uses - please let us know - we are working on how
>>> much we need to expose this in the JVMS draft.
>>>
>>> thanks,
>>> Karen
>>>
>>>> On Jun 5, 2017, at 1:46 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>>
>>>> Hi Remi,
>>>>
>>>> Yes thanks for clarifying, which simplifies things API-wise and makes sense in
>>>> hindsight when considering just primitives.
>>>>
>>>> I am still getting to grips with this Q-type stuff, excuse my ignorance. The top
>>>> value wrapper type (currently __Value) is sort of a box or carrier, but one
>>>> without identity with immutable contents and the VM can single them out for
>>>> optimisation. Correct?
>>>>
>>>> Paul.
>>>>
>>>>> On 3 Jun 2017, at 06:56, Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 03/06/17 12:51, Remi Forax wrote:
>>>>>> Hi Paul, Hi Maurizio,
>>>>>> bindTo() or insertArguments use the corresponding types from the method type to
>>>>>> unbox the argument if necessary,
>>>>>> so actually bindTo(3) will insert 3 and not the boxed Integer if the
>>>>>> corresponding type is an int.
>>>>>>
>>>>>> The same way, a boxed value type can be unboxed if the corresponding type is a
>>>>>> Q-type,
>>>>>> so there is no need of a bindTo(__Value).
>>>>>>
>>>>>> In term of performance, this is not an issue because neither bindTo() nor
>>>>>> insertArguments() should be called on a fast path.
>>>>> Yeah - thanks for the clarification - this corresponds to my understanding of
>>>>> the model - that is, with BMH, boxing happens 'at the boundaries', when you set
>>>>> up the method handle chain - but I think that in order to get there you need at
>>>>> least to teach BMH about value types (that is, the Species_XYZ classes should
>>>>> have methods to construct bound versions with value types), otherwise the chain
>>>>> will just get boxed to Object internally.
>>>>>
>>>>> Maurizio
>>>>>> regards,
>>>>>> Rémi
>>>>>>