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

[Vladimir Ivanov]

http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.00
https://jbs.oracle.com/bugs/browse/JDK-8027827
354 lines changed: 193 ins; 91 del; 70 mod

OVERVIEW

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}:L=ValueConversions.array(a1:L,...,a_{k}:L);
t_{i+1}:L=MethodHandleImpl.guardWithCatch(t_{p1}, t_{p2}, t_{p3}, t_{i}:L);
  t_{i+2}:I=ValueConversions.unbox(t7:L);
      OR :L=ValueConversions.identity(t_{n+1})
      OR :V=ValueConversions.ignore(t_{n+1})

where:
   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.

FURTHER WORK

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).

TESTING

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

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

OTHER

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.

Thanks!

Best regards,
Vladimir Ivanov

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