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