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

[Jochen Theodorou]

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.

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?

bye Jochen

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
>