Condy for LambdaMetafactory?

[John Rose]

On 20 Oct 2023, at 13:59, Brian Goetz wrote:

> The optimization is appealing because condy linkage is cheaper than indy linkage, and because it would allow more sharing between identical lambdas in the same file (they'd map to the same condy, which would only have to be resolved once.)

Using unshared lambdas has a small advantage which is sometimes significant.
Lambdas accumulate type profiles, and those type profiles add an extra
hidden layer of customization to the lambdas, exploited by the JIT sometimes.

So you might have two identical lambdas, for which the JIT produces completely
different code, because it devirtualizes something in the lambda (after
inlining the desugared body), and devirtualizes differently for the two
different lambdas.

All I’m saying here is that sharing is not always a win.  Sometimes the
opposite move, splitting and customization, is the performance win,
even though you have two copies of the code in the end.

So, Luke is proposing an interesting experiment, one which is likely to
improve startup and footprint, but could also leave some technical debt
to the profiler and JIT.  Note also that JIT code quality impacts
startup and warmup; you can see startup itself get worse if you do
something the JIT doesn’t like.

The fun thing about invokedynamic (unlike any other instruction) is that
it relinks itself for every distinct occurrence of the instruction.
(Other instructions become fully linked as soon as their CP entries
link, so sharing or splitting the instructions does not affect the
resolution of CP entries.)  If you have two identical invokedynamic
instructions, they incur two resolutions.  This means the LMF might
possibly spin two identical but distinct lambda classes.  That might
seem to be a waste, but there are hidden benefits.  The invokedynamic
instruction turns the default towards “split them all” while the
condy constant turns it towards “share them all”.