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

[Vladimir Ivanov]

Sigh, it's not so simple... I forgot about 8034120 [1].

The problem is that MH.invoke/invokeWithArguments have unpleasant effect 
for VarargsCollector. It introduces a difference in behavior between 
interpreting LF and executing compiled version.

Filed 8036117 to track the problem.

Best regards,
Vladimir Ivanov

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

On 2/28/14 12:39 AM, John Rose wrote:
> On Feb 26, 2014, at 3:44 AM, Vladimir Ivanov
> <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>> wrote:
>
>>>
>>> Maybe use invokeWithArguments with target and catcher?  That at least is
>>> a one-liner, and probably more efficient.
>>
>> Yes, that's a good idea! At least, it considerably simplifies the code.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.03/
>
> Thumbs up.
>
> Your use of invokeWithArguments in the unspecialized code is a good
> design pattern.  The semantics are clear in the original method.  This
> in turn gives a clear basis for specializing for each combination of
> argument arities and types.  Specialization should be done using
> low-level, high-leverage mechanisms like bytecode spinning or even JIT
> optimizations.
>
> Put another way, if we have reasonable bytecode-generation intrinsics,
> feeding to good JIT optimizations, we don't need top-level
> specializations in the source code.  The need for those has always been
> a mark of weakness in the HotSpot implementation of MHs.  (Fredrik's
> JRockit implementation did it all in the JIT!)  We will continue to push
> down specializations to lower layers.
>
> — John