deduplicating lambda methods

[Vicente Romero]

Hi all,

Although there are still areas under discussion I think that we should 
go for a 'final', pushable version of the patch, which I think should be 
based on the last iteration sent by Liam, plus code based in the changes 
I proposed to don't go deeper in the tree comparison as soon as a 
constant is found, plus regression tests. We can continue discussing 
about the no-op filtering proposed by Bernard and if we have data 
supporting that change, we can include it in a next iteration. I think 
that we all mostly agree on the consistency of the state I'm describing, 
so I think we should go for it,

Thanks,
Vicente

On 03/02/2018 08:03 PM, Liam Miller-Cushon wrote:
> Hello,
>
> I'm interested in adding support for deduplicating lambda methods to 
> javac. The idea is that if a compilation unit contains two lambdas 
> that are identical (including any captured state and the functional 
> interface they implement) we could re-use the same implementation 
> method for both.
>
> I understand there might have been some prior discussion about this. 
> Is there interest in investigating the feature? What sort of technical 
> considerations have been identified so far?
>
> I have been thinking about a couple of questions:
>
> 1) How to identifying duplicates: I have a prototype that runs during 
> lambda desugaring and identifies duplicates by diffing ASTs. Is that 
> the best place for deduplication, or it worth considering comparing 
> generated code instead of ASTs?
>
> 2) Debug info: the optimization is safe if line numbers are not being 
> emitted. If they are, is there a way to deduplicate the methods 
> without breaking debug info?
>
> Thanks,
> Liam