deduplicating lambda methods

B. Blaser bsrbnd at
Sun Mar 4 12:39:01 UTC 2018

On 3 March 2018 at 05:01, Vicente Romero <vicente.romero at> wrote:
> very interesting!
> 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?
> are you doing an exact diff? I assume that we want: s -> s to be equal to z
> -> z provided that the target is the same
>> 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?
> I haven't tried to debug a method with more than one LNT, the spec allows it
> but not sure how IDEs will operate on that

Interesting, but every dynamic call site would have to identify the
right LNT and link it to the corresponding lambda instance via the
bootstrap method so that a debugger could find it at runtime... is
this already done?

Note that, as recently discussed on compiler-dev, the indy line number
is currently not emitted (causing some stack trace problems) but the
lambda line numbers have to be emitted to step into the latter, is
this currently done (I've not verified)?


>> Thanks,
>> Liam
> Vicente

More information about the amber-dev mailing list