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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Mon Mar 3 10:31:40 UTC 2014

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

More information about the core-libs-dev mailing list