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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
