deduplicating lambda methods

[Vicente Romero]

Hi Bernard,

On 03/04/2018 07:39 AM, B. Blaser wrote:
> On 3 March 2018 at 05:01, Vicente Romero <vicente.romero at oracle.com> 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

Vicente

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