deduplicating lambda methods

[John Rose]

On Mar 7, 2018, at 8:25 AM, B. Blaser <bsrbnd at gmail.com> wrote:
> 
> Looking at the stats [1], we see that most of the cases are trivial
> and mostly related to primitive & boxing types. I'm wondering if JIT
> profiles would be affected if de-duplication was simply focusing on
> those trivial cases?

Good questions.

Type profiling is mostly on receivers of virtual calls, sometimes on
other arguments or return types, and also on casts and instanceof.
Branch profiling is on control flow branches, of course.

If a trivial lambda has no such constructs, it's likely that its profile
contributes little to the JIT.

> If profiles were not polluted in such cases, It wouldn't be necessary
> to "create distinct profile points for every distinct spot in the
> source code".

Correct.

> But I'm still wondering what to do with the LNT/LVT (as debugging
> information might be lost when merging lambdas)?

There might be a performance cost here associated with debuggability.
That's rare in Java, but still happens from time to time.  The resolution
might be to arrange things so that the optimization choice is
pushed to runtime, so that the slow-down occurs only in JVMs
which somehow know that they are debug mode.  Doesn't save
the case of attaching to a JVM already started in production mode.

This feels like a follow-on project, because it may require very
specific refactorings either inside the LMF or to the LMF API to
accept contextual information from the capture site, and either
discard it conditionally, or put it in some sort of side container
specially engineered to be available to debuggers but not affect
code identity.  And that might require tweaks to debug APIs.

> 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.

— John