[mvt] RFR MVTTest refactor

[Maurizio Cimadamore]

This looks great! The very fact that the test works seems promising - of 
course there will be intermediate 'unwanted' boxing (which we'll want to 
get rid of), but it seems like the prototype can handle some degree of 
combinators well, which should enable some real world end to end testing.

I think you should be a Valhalla committer - in case you have any issue 
please ping me and I'll push for you.

Thanks again!
Maurizio


On 07/06/17 05:22, Paul Sandoz wrote:
> http://cr.openjdk.java.net/~psandoz/valhalla/mvt-test/webrev/test/valhalla/mvt/MVTTest.java.sdiff.html 
> <http://cr.openjdk.java.net/%7Epsandoz/valhalla/mvt-test/webrev/test/valhalla/mvt/MVTTest.java.sdiff.html>
>
> Also includes a test with a counted loop (although i have yet to look 
> at how that behaves regarding LFs).
>
> Paul.
>
>> On 2 Jun 2017, at 15:54, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com 
>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>
>>
>> On 02/06/17 18:50, Paul Sandoz wrote:
>>>> On 2 Jun 2017, at 10:27, Maurizio Cimadamore 
>>>> <maurizio.cimadamore at oracle.com 
>>>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>>>>> But the other flip of the coin is to handle APIs - if you have a 
>>>>>> method handle that takes a Q-type, how do you 'bind' its 
>>>>>> argument? The APIs we have today are boxy. Some of these APIs are 
>>>>>> used internally by some of the BMH classes, so you could hit them 
>>>>>> through combinators too.
>>>>>>
>>>>> Yeah:
>>>>>
>>>>>   public MethodHandle bindTo(Object x)
>>>>>
>>>>> Do we need something like:
>>>>>
>>>>>   public MethodHandle bindToValue (__Value v)
>>>>>
>>>>> ?
>>>>>
>>>>> Such a bifurcation is somewhat awkward.
>>>> Yep - it does look odd.
>>>>
>>>> The current working theory is that BMH should work (but will add 
>>>> boxing via asType adaptation) - so, in terms of capabilities, we 
>>>> should be there already.
>>>>
>>>> When the time comes, I think we should look at some of the complex 
>>>> combinators (I'm looking at you for loop :-)) and see whether 
>>>> intermediate boxing causes excessive penalty there.
>>>>
>>> A start would be to add a simple loop test traversing over an array 
>>> of Point reducing to one resulting Point. I can add something to the 
>>> MVTTest, and perhaps refactor into more clearly separated tests of 
>>> functionality.
>> That'd be great - thanks! MVTTest is an hacky smoke test I've written 
>> to validate all the features of ValueType MHs. As such is by no means 
>> complete - it'd be great to have more stuff added to it, or to break 
>> it up by functionality as you proposed.
>>
>> Maurizio
>>
>>
>>>
>>> Paul.
>>
>