deduplicating lambda methods

[Liam Miller-Cushon]

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.

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.