deduplicating lambda methods

B. Blaser bsrbnd at gmail.com
Sat Mar 17 15:02:43 UTC 2018


On 15 March 2018 at 19:52, Liam Miller-Cushon <cushon at google.com> wrote:
> On Wed, Mar 7, 2018 at 11:38 AM John Rose <john.r.rose at oracle.com> wrote:
>>
>> > Note that the only risk is to point to another lambda in the source
>> > file but with the same code…
>>
>> …Or if we take the option to globalize some "top ten" list of shapes.
>> Then you'd step into a lambda body in some java.base library.
>> (Or maybe not step at all?)
>>
>> If your single-stepping takes you to a lambda with the same shape
>> as the one you expect to single-step into, but the source location
>> you actually reach looks unreached, it's confusing but arguably OK.
>>
>> After all lambda identity (as an object) is not guaranteed, and can
>> be pre-allocated.  To the debugging programmer, it looks like the
>> compiler and/or JVM chose to preallocate the same lambda but
>> in a different place.  Exact source locations are debatable in a way
>> expression semantics are not.  Again, full debuggability sometimes
>> conflicts with full performance.
>
>
> I agree that stepping in to a lambda body and jumping to a different line
> with identical code might not be *too* surprising.
>
> Perhaps more concerning is the handling of breakpoints: if a breakpoint
> is set in a lambda body that gets deduplicated (or is implemented
> using one of the globalized lambdas), the breakpoint will never be hit.
> This seems more confusing and harder to work around than stepping to
> an incorrect but equivalent line.

In this case, I think the debugger (or the debug API?) would have to
map all corresponding breakpoints to the reference (merged or shape)
lambda maybe producing some unnecessary breaks when debugging but
without misses.

Bernard

> I don't have any good ideas here aside from something like the follow-on
> project you described of adding additional information to the capture site
> that could be used by the debugger. That sounds feasible but non-trivial,
> and I wonder whether lambda deduplication alone provides enough
> motivation to add support for that.


More information about the amber-dev mailing list