I think avoiding to create many of them is actually not trivial. The
indy port of Groovy has a similar problem. And I do have to use a lot of
insertArguments, exception catching handles and other things. So the
stress is actually pretty high at times.

Can you elaborate a bit, please? What kind of stress do you observe: MH instantiation overhead or increased footprint? Does memory increase come from method handles alone or there are plenty of classes loaded at runtime for compiled LFs?

example... foo(x,y) is mapped to MyInvokerFallback.handle(receiver,
"foo", x, y); with the method taking a String and an Object[]. How do I
get the name in there without insertArguments? Don't I have to create at
least one handle per name I find?

One important detail is how method handles are actually used.

Yes, you do have to create a method handle per call site, but it is placed in a CallSite instance and bound to indy call site. In that case, there's no need in LambdaForm specialization: JIT-compiler will inline the whole method handle chain at indy call site which is equivalent to bytecode specialization.

Also, LambdaForms are aggressively shared, so you shouldn't observe significant growth in their number at runtime (unless there are lots of unique "erased" signatures present; that's where LF sharing can't help now).

Hope it helps. FTR I covered some of those topics in details in my j.l.i-related talk at JVMLS'15 [1].

Best regards,
Vladimir Ivanov


On 04.05.2017 08:16, John Rose wrote:
On May 3, 2017, at 9:37 PM, Wenlei Xie <
<>> wrote:

Thank you Vladimir for the help ! I see the point why MH.bindTo() is
not a good fit for implementing lambda capturing.

A simple rule for using MHs is that they are designed to be another form
of code.
Creating many of them at a high rate is likely to stress JVM in ways
to loading many small classes at a high rate.

So bindTo is really code customization, which is not the same thing as
data capture.
The MH before bindTo is an algorithm with a variable "hole" in it, where
the MH after
bindTo is a customized version of the algorithm, with the hole filed by
a constant.
It's a little like a C++ template instance.

I'd like high-count bindTo to be cheaper, of course, but it's not the
design center,
and it's not where we are investing optimization effort.  Maybe in the

— John

mlvm-dev mailing list

mlvm-dev mailing list
mlvm-dev mailing list

Reply via email to