Thanks, Marcus! Best regards, Vladimir Ivanov
On 2/20/14 7:31 PM, Marcus Lagergren wrote: > This looks good, and we have done a significant number of test runs to verify > its integrity. > > I say ship it. +1 > > We know that there are some issues with > sun.misc.ValueConversion.castReference and similar internal methods not being > inlined, but as far as I can understand this is a separate issue that will be > addressed. By rewriting a guard for Nashorn to not use castReference in the > fast case, I get record indy performance with your catch combinator. > > /M (jdk9 reviewer) > > On 19 Feb 2014, at 22:46, Vladimir Ivanov <vladimir.x.iva...@oracle.com> > wrote: > >> 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
