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

[Vladimir Ivanov]

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.ivanov at 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
>