On 03/22/2013 07:57 AM, Jochen Theodorou wrote:
> Am 21.03.2013 20:31, schrieb Krystal Mo:
>> Hi Jochen,
>>
>> At least with the current tip version of HotSpot, the
>> mh.invokeWithArguments() callsite is not likely to get its actual target
>> inlined into the caller; we depended a lot on being able to prove that
>> the MethodHandle is a (JIT-)compiled-time constant to be able to do
>> inlining across the MethodHandle.invoke/invokeExact boundary.
> ah yes, I forgot that.
>
>> I'm working on adding profiling support for
>> MethodHandle.invoke/invokeExact (which invokeWithArguments() will call),
>> and it looks at what MethodHandles get passed in.
>> When that work lands in HotSpot, your example will be a source of
>> profile pollution just like the well-known megamorphic callsites in the
>> old days, so I wouldn't suggest doing that.
> ok, thanks. I guessed it would be.
>
> but maybe some can give my an alternative solution then. My "problem" is
> that if you have a Java program (1.7) and that is supposed to call
> something available as MethodHandle, and several of these, then you have
> either a big useless try-catch or several of them, bloating your code a
> lot. My idea with
>
>> public static Object invoke(MethodHandle mh, Object[] args) {
>> try {
>> return mv.invokeWithArguments(args);
>> } catch (Throwable th) {
>> ExceptionUtils.sneakyThrow(th);
>> }
>> }
> was to give an alternative way of calling, without having to try-catch
> every time. Then sam conversion seems to be the only way left for this.
I don't think it's a good idea to expose directly method handles to users,
it's better to encapsulate it into a Groovy object corresponding to a
function
or a closure so you can add a bunch of invoke overloads.
>
> bye blackdrag
>
cheers,
Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
