deduplicating lambda methods

Vicente Romero vicente.romero at
Sun Mar 4 16:38:03 UTC 2018

Hi Bernard,

On 03/04/2018 07:39 AM, B. Blaser wrote:
> 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)?

no we haven't done any change to this area yet

> Bernard


>>> Thanks,
>>> Liam
>> Vicente

More information about the amber-dev mailing list