On 03/22/2013 11:50 AM, Remi Forax wrote:
On 03/22/2013 11:12 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:35, schrieb Remi Forax:
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
I don't think it's a good idea to expose directly method handles
On 03/23/2013 04:30 PM, Peter Levart wrote:
On 03/22/2013 11:50 AM, Remi Forax wrote:
On 03/22/2013 11:12 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:35, schrieb Remi Forax:
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
I don't think it's a
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 that in
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
On 03/22/2013 07:52 AM, Jochen Theodorou wrote:
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
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
On 03/22/2013 10:06 AM, Remi Forax wrote:
On 03/22/2013 07:52 AM, Jochen Theodorou wrote:
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
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
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.
what invoke overloads are you
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
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
Am 22.03.2013 10:35, schrieb Remi Forax:
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
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
On 03/22/2013 11:12 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:35, schrieb Remi Forax:
On 03/22/2013 10:24 AM, Jochen Theodorou wrote:
Am 22.03.2013 10:11, schrieb Remi Forax:
[...]
I don't think it's a good idea to expose directly method handles to users,
it's better to encapsulate it
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
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
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-time
14 matches
Mail list logo
