deduplicating lambda methods
vicente.romero at oracle.com
Mon Mar 26 13:20:58 UTC 2018
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,
On 03/02/2018 08:03 PM, Liam Miller-Cushon wrote:
> 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?
More information about the amber-dev