RFR 8183146 [MVT] Create composed vwithfield constructor

[Paul Sandoz]

> On 30 Jun 2017, at 04:15, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Paul,
> 
> ----- Mail original -----
>> De: "Paul Sandoz" <paul.sandoz at oracle.com>
>> À: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoyé: Vendredi 30 Juin 2017 02:42:06
>> Objet: RFR 8183146 [MVT] Create composed vwithfield constructor
> 
>> Hi,
>> 
>> Please review the following:
>> 
>> http://cr.openjdk.java.net/~psandoz/valhalla/c-wither/webrev/
> 
> 
> I think the doc comment should be
> 
> // (F1, ..., Fn)Q, if fromDefault == true
> // (Q, F1, ..., Fn)Q, if fromDefault == false
> 
> because the return value is a specific Q-type.
> 

Ok.


> and the last parameter types should be a varargs (Field... instead of a Field[]).
> 

Ok.


>> 
>> This adds a method, named unrefllectWithers for want of a better name, that
>> given a number of fields can produce a method handle that applies vwithfield,
>> in order with each Field. SO it should produce some tight byte code for the
>> production of values, which then can be optimized by the JIT (e.g. if a default
>> value is obtained and all fields are updated then the JIT could optimize away
>> the zeroing associated with vdefault).
> 
> given that you can bind the result of vdefault, i'm not sure you need the boolean fromDefault.
> 

I don’t wanna box the result of vdefault in a bound method handle, there are certainly other ways (like with collectArguments used in the test), but i want the byte code to be really “tight” so the VM can optimize the vdefault + vwithfield* pattern really well.


>> 
>> This method is quite general, depending on the arguments passed in, it can
>> reduce to an identity function, findWither, or defaultValueConstant, which
>> suggests the latter two could defer to this method.
>> 
>> Rather than accepting an array of Field[] it should perhaps be a
>> LinkedHashMap<String, Class<?>>, or two distinct arrays of the same size,
>> String[] and Class[]. In any case we need a way for the caller to specify the
>> set of fields in a defined order.
> 
> This method is the underlying method you need to implement chip pattern matching extractor,
> (i'm sure i'm not the only one to have thought about that :) )
> for that use case, the values will comes as fields from  a call to getDeclaredFields() (with a permutation in between).
> 

Good point.

Paul.