where are our performance bottlenecks?

Rémi Forax forax at univ-mlv.fr
Tue Jul 5 07:40:12 PDT 2011


On 07/05/2011 04:04 PM, Christian Thalinger wrote:
> Now that we are done with 7 I'm looking into performance issues we have.  Are there any that you know of and would like to get fixed for 7u2?

Sound like Xmas to me.
So Dear Santa Claus,

1) Remove the method handle check done when the method handle tree is JITed.
     This require to deoptimize if setTarget() is called after being JITed.

2) Store MDO like information in method handle corresponding to
     GuardWithTest method, non-bound method call (vtable call), etc
     and transfer these info to the MDO when the method handle tree is 
JITed.

3) Make escape analysis works with invokedynamic and with method handle
     that are constants.

4) Implement SwitchPoint optimization i.e when a SwitchPoint is JITed, 
do noting
     but register a dependency between the SwitchPoint and the JITed code.
     When the SwitchPoint is invalidated, invalidated the JITed code
     (replace it by an interpreter call (until being re-JITed :))

5) Tweak the loop optimizer to recognize loop with a method handle call 
in the middle
      in order to hoist the method handle checks ouside the loop.
      for(...) {
         mh.invoke(args...);
      }
      should be re-written:
      if (mh == cstMH) {
         for(...) {
           mh.invoke(args...);  // here we can now inline :)
         }
      } else {
         deoptimize();
      }

      After, instead of maintaining one version of the loop,
      keep several versions in a hashmap like data structure.

6) Implement ClassValue optimization. Reserve a predefined number of slots
     in each Class object and when a ClassValue is created, use one of 
this slot
     if available instead of relying on the hashmap.
     This optimization is less important because I haven't seen a use 
case that use
     ClassValue in the fast-path.

> -- Christian

BTW, I super-swear to be a good kid this year.

Rémi




More information about the mlvm-dev mailing list