Condy for LambdaMetafactory?

[Maurizio Cimadamore]

On 24/10/2023 11:22, Tagir Valeev wrote:
> With -g the measured time is about 1800ms, while without -g it's about 
> 6ms. That's because when lambdas are deduplicated, type profile for 
> map() method is clean, and the whole stream can be inlined, and even 
> the loop could be likely replaced with a constant. When lambdas are 
> not deduplicated, this is not the case: type profile is polluted, and 
> the whole stream cannot be inlined. So, deduplication can actually 
> improve the performance, at least in such extreme cases.
Very interesting results - thanks! I believe it works well because when 
deduplication kicks in, the body is _really_ identical, so there's no 
value in keeping separate profiling info for the three lambdas. Well, 
maybe, maybe not. If your lambda has some conditional code (`if (cond) 
...`) and one lambda is always used where cond = true and the other 
lambda is always used where cond = false, this might be a problem as the 
profile of the deduplicate lambda might get polluted. So I'm not sure 
how reliably this technique would actually work out in practice as a way 
to improve performance.
> By the way, while experimenting with this sample, I've noticed that 
> deduplication of this particular code is broken since Java 18 (the 
> code performs slowly both with and without -g, and reading the 
> bytecode confirms that no deduplication is done). Should I report, or 
> probably there's no interest in supporting this feature?

Oh - I wasn't aware of this issue - regardless of what we wanna do with 
this feature moving forward, filing a bug is always the right thing to 
do, to make sure it doesn't fall off the radar.

Thanks
Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231024/bc652c6c/attachment.htm>