MethodHandle performance

Remi Forax forax at
Fri Jan 13 19:37:41 UTC 2017

The problem is more that if you have played a little with the API, you know that invokeWithArguments is slow because it may do a lot of work with no way to cache the intermediary representation into the user code (and even if you add a cache, it will not handle all the cases, if the arrays do not have the same size or if the signature of the mh is not generic, etc). 

I think we (the JSR 292 EG) have failed here, we should not have introduced a method which is perhaps too convenient but hard to optimize.

Why not adding a line in the javadoc of invokeWitharguments, saying something like this:
Don't expect invokeWithArguments to be fast! Use invokeExact or invoke if you need performance.


----- Mail original -----
> De: "John Rose" <john.r.rose at>
> À: "Claes Redestad" <claes.redestad at>, "Stephen Colebourne" <scolebourne at>
> Cc: "jigsaw-dev" <jigsaw-dev at>
> Envoyé: Vendredi 13 Janvier 2017 20:04:20
> Objet: Re: MethodHandle performance

> On Jan 12, 2017, at 12:29 PM, Claes Redestad <claes.redestad at> wrote:
>> Right, I was just looking at the micro Stephen provided me, and it does
>> seem that the added cost for this case is due to invokeWithArguments
>> creating a new invoker every time.
> This is a good workaround, and Stephen's report is a helpful reminder
> that our performance story has a sharp edge.
> We cache spreaders in the case of varargs methods,
> for full performance, but not for the ad hoc spreader used by MH.iWA.
> We should cache them, to remove this sharp edge (or performance pothole).
> There are small technical challenges to do so.  Claes and I added
> some notes to the bug report; maybe someone can look into it more.
> — John

More information about the jigsaw-dev mailing list