loop customization: a key challenge (original) (raw)

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Sep 10 11:50:38 PDT 2012

On 09/10/2012 09:28 PM, John Rose wrote:

There is an important optimization challenge coming up when lambdas are combined (as they are intended to be combined) with bulk data processing libraries. I call this optimization challenge "loop customization".

Thanks for a nice writeup!

Actually, we thought about this as well in the context of lambda-accepting methods, the prime example being bulk operations. This is something bugging us as well.

(Can anyone propose a previously coined, commonly used term instead of loop customization? Please read on…)

I think this is not about the loops per se, albeit the impact is mostly visible in the loops, where you bang yourself of this issue over and over and over again. But this applies to any other (linear) optimization.

With closures, there is another option for triggering customization, and that is partial application. [1] L0 should create a customized inner loop L1+X, not by eventually calling X from L1 inside each worker thread, but by partially applying L1 to X at top level, before splitting the workload.

This looks like to attempt to translate the argument type dispatch [*] to receiver type dispatch which we are able to optimize well already. Do we have other options for syntax/semantic convention to tell VM "see this argument? You better specialize on it's type"? Given John's conversion is probably forced by the user, I think syntactical brevity is the significant concern even for hard-core library developers.

-Aleksey.

[*] Granted, the dispatch for the copies of the same method, but each with specialized type constraints.

More information about the hotspot-compiler-dev mailing list