[9] RFR (M): 8027827: Improve performance of catchException combinator

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed Feb 19 21:46:10 UTC 2014

354 lines changed: 193 ins; 91 del; 70 mod


MethodHandles.catchException combinator implementation is based on 
generic invokers (MethodHandleImpl$GuardWithCatch.invoke_*). It is 
significantly slower than a Java equivalent (try-catch).

Future Nashorn performance improvements require catchException 
combinator speed to be on par with try-catch in Java.

So, it should be represented in a more efficient form.

I chose the following lambda form representation:

t_{i+1}:L=MethodHandleImpl.guardWithCatch(t_{p1}, t_{p2}, t_{p3}, t_{i}:L);
      OR :L=ValueConversions.identity(t_{n+1})
      OR :V=ValueConversions.ignore(t_{n+1})

   a1, ..., a_{k} - arguments
   t_{p1}, t_{p2}, t_{p3} - target method handle, exception class, 
catcher method handle respectively; passed as bounded parameters;

During lambda form compilation it is converted into bytecode equivalent 
of the following Java code:
   try {
       return target.invokeBasic(...);
   } catch(Throwable e) {
       if (!exClass.isInstance(e)) throw e;
       return catcher.invokeBasic(e, ...);

There's a set of microbenchmarks (attached to the bug) I wrote to verify 
performance characteristics of new implementation.


What is missing is lambda form caching. The plan is to have a single 
lambda form per basic type, but it needs more work - current 
representation is suitable for sharing on bytecode level, but lambda 
form interpretation doesn't work well (arguments boxing + result 
unboxing are problematic).


Tests: microbenchmarks, jdk/java/lang/invoke/, nashorn with optimistic 
types (unit tests, octane).

Tested in 2 modes:
   * COMPILE_THRESHOLD=0 -Xverify:all


1) Update of cached name and member in LF compilation loop (see 
InvokerBytecodeGenerator.generateCustomizedCodeBytes) fixes a bug during 
compilation of selectAlternative when running with COMPILE_THRESHOLD=0.

2) As part of this change, I fix existing bug [1], so I add regression 
test for it.


Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8034120

More information about the core-libs-dev mailing list