Implementing Lambda with Capture support makes Metaspace fills LambdaForms$BMH class

[Vladimir Ivanov]

Jochen,

> 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

[1] http://cr.openjdk.java.net/~vlivanov/talks/2015-JVMLS_State_of_JLI.pdf

> On 04.05.2017 08:16, John Rose wrote:
>> On May 3, 2017, at 9:37 PM, Wenlei Xie <wenlei.xie at gmail.com
>> <mailto:wenlei.xie at gmail.com>> 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
>> similar
>> 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
>> future.
>>
>> — John
>>
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev