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

[Jochen Theodorou]

On 04.05.2017 15:05, Vladimir Ivanov wrote:
> 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?

My biggest problem in terms of creation performance are transformations 
of the handle using asType so far. Having to create many many different 
MethodHandles increases the memory footprint, but probably stabilizes. 
As for plenty of classes... well.. potentially yes. I can easily create 
such a program in Groovy.

>> 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.

is that now true for all handles? Since the forms do no longer show up 
in the traces I cannot tell. Also I am required to have MutableCallsite, 
since I have to handle the dispatch based on runtime types. This 
multiplies the number of handles I create. Example:

Object myMethod(Object singleArg);
Object myMethod(String singleArg);

myMethod(x)

In Java, now depending on the defined type of x we know which of the two 
methods to call. Which means, if I could use a static callsite here. In 
Groovy I have to first put in a handle, that directs to my method 
selector, which will then install the target handle (and call it), as 
well as a guard to check that the argument is as expected.

> 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).

there is a high number of "runtime signatures"

bye Jochen