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:

Yes, it's true for all handles. LF specialization is tightly coupled with JIT-compilers and is triggered only for method handles which aren't inlined into all callers. It never happens for indy call sites - JITs can always inline (and do so) through them. (Even when they are linked to mutable CSs. In that case, there's a dependency on compiled method registered to track future modifications.)

But I suspect it's not what you asked about.

FYI with -XX:+ShowHiddenFrames the JVM will include LF frames in stack trackes. But it's not about stack frames: there's still a single frame per method handle in a method handle chain in interpreter.

LambdaForm specialization is about generating a dedicated class for a LambdaForm instance.

So, irrespective of LF specialization, you'll observe the same number of stack frames, but the methods being executed will refer to either shared or customized LFs.

In other words, LF specialization influence how many classes for compiled LFs are loaded, but doesn't change what actually happen during MH invocation. (No inlining on bytecode level is needed during specialization. JIT will already do that during compilation. No need to help it.)

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


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.

I'd like to differentiate method handles and lambda forms. If you create a new method handle, it doesn't imply a new lambda form is also created.

Method handles aren't compiled to bytecode themselves, only lambda forms are. So, when you instantiate a new method handle, from footprint perspective you pay a cost of a single object instance. Most likely, the costs of the lambda form & associated class are amortized across all method handles which share them.

For example, my experiments with Nashorn showed 1000x ratio between instantiated MHs & LFs (millions handles vs thousands LFs on Octane benchmarks).

Also, LF caches are SoftReference-based, so footprint measurements don't reflect how many LFs are actually used. It's pretty expensive to construct a LF, so it's benefitical to keep it alive longer that weak references allow.

You mentioned MH.asType() and, unfortunately, from LF sharing perspective it's a weak point right now. There's some sharing possible, but the current LF shape for asType() transformation is hard to share.

It hasn't been addressed yet mostly because we don't have a good understanding how much overhead does it cause. So, if you have any data on that, please, share.

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

there is a high number of "runtime signatures"

What is important is how many unique erased signatures exist (erased to basic types [1]). It's still possible to trigger explosion in number of LFs (5^255 is still pretty large, isn't it? ;-)), but now it's a corner case.

Best regards,
Vladimir Ivanov

[1] 5 in total: int, long, float, double, Object
mlvm-dev mailing list

Reply via email to