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

[Remi Forax]

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.

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