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-
Am 21.03.2013 20:49, schrieb Remi Forax:
[...]
> I suppose you take a look to the instances.
> You can do something similar actually by using invokedynamic +
> a guardWithTest that checks already seen instances instead of doing a
> plain mh.invoke*
> I think Duncan and Georges do something like tha
On 03/21/2013 08:31 PM, Krystal Mo wrote:
> 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
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 t
Maybe I'm misunderstanding your question, but whether
mh.invokeWithArguments(args) internally generates a mono, poly, or
megamorphic call site internally in the JVM is going to depend on the
implementation and just how many subclasses of MethodHandle there are.
If you're concerned about the implem
Hi all,
assuming I have in Java a method:
public static Object invoke(MethodHandle mh, Object[] args) {
try {
return mv.invokeWithArguments(args);
} catch (Throwable th) {
ExceptionUtils.sneakyThrow(th);
}
}
(sneakyThrow is to work around checked exceptions and does basically
