loop customization: a key challenge

[Aleksey Shipilev]

On 09/10/2012 11:13 PM, John Rose wrote:
> On Sep 10, 2012, at 11:50 AM, Aleksey Shipilev wrote:
> 
>> "see this argument? You better specialize on it's type"
> 
> That's why the JSR 292 EG put MH.bindTo and Lookup.bind into the API,
> even though MHs.insertArguments is more general.
> 
> The methods strongly hint to implementors and users that bind and
> findVirtual + bindTo perform the obvious devirtualization.

I haven't been following jsr292 development recently. Is that kind of
hint already favored by Hotspot? I would like to try to do this
conversion by hand and see if it helps some of our benchmarks here.

> Of course, loop customization does not really appear to be a case of
> devirtualization… unless perhaps you treat each loop superstructure as a
> defender method on the loop kernel interface.  Then L1_X is really X.L1,
> and the JVM optimization framework can swing into action, cloning L1
> into each receiver type X.  So that's a MH-free way to think about it.

Yes, it appears that your suggestion applies to whatever
"superstructure" there is in the code. I would like to highlight that
the obvious demarcation point for such the superstructure is the method
call, and we can probably spare some of the syntactical pain and
hard-core conspiracy from the library developers. I.e. if there is a way
to say

class Arrays {
 void <T> apply(T[] array, @PleaseSpecialize UnaryOperator<T> op) {
     // blah-blah, apply
 }
 ...
}

...albeit being more limiting in "superstructure" sense, it is more
clear than explicitly writing up jsr292 magics. Of course, in this
sense, we can even try to desugar this to jsr292 with the conversion
outlined by John, e.g. into:

class Arrays {
 void <T> apply(T[] array, @PleaseSpecialize UnaryOperator<T> op) {
    MH superOp = #apply$$Internal.bindTo(op);
    superOp.invoke(array);
 }
 void apply$$Internal(UnaryOperator<T> op, T[] array) {
     // blah-blah, apply
 }
}

-Aleksey.