deduplicating lambda methods

[B. Blaser]

On 6 March 2018 at 03:27, John Rose <john.r.rose at oracle.com> wrote:
> On Mar 5, 2018, at 3:37 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> Now, with indy, I believe we can still optimize them fully, given that indy has some knowledge/state about the site making the call, so the two call won't be treated as 'identical' by the JIT and the profiling info won't be merged (I guess). But what if, someday, we were to replace indy with condy here? Would we lose performances?
>
> Deduplication of code always has the risk of lower performance,
> if the deduplicated code has a profile that the JIT might rely on.
>
> Duplicated code can sometimes collect crucial profile data which
> deduplicated code would miss.

[...]

> Currently each lambda indy is a distinct lambda factory call,
> so that lambda gets its own adapter code and hence its own
> profile and static types.  If the desugared body is simple and
> inlines, then the JVM has a good chance at optimizing it,
> regardless of the quality of the desugared body's profile.
> But if the body is complex, the applicability of the adapter's
> static types and profile will only apply "around the edges".
>
> So if two lambdas share a desugared body (whether locally or
> globally), the profile of that body might be polluted, but some
> (not all) of the pollution can be cleaned up if the JIT finds
> useful context in each indy site.  The lambda bodies that
> are best suited for this are ones which mainly call methods
> on argument objects already seen (and maybe profiled)
> by the lambda's adapter object (FI implementation).
> A lambda body which creates a temporary value of
> a statically unpredictable type might fall off the cliff sooner,
> if it is shared and the sharing makes it harder to get
> a monomorphic profile on the unpredictable type.
>
> These rules of thumb are generally valid, but specific
> results are not robust, since JVM optimization techniques
> change over time.

[...]

> One way to preserve more contextuality from translation
> of lambdas is to retain indy in the translation strategy,
> but use condy to hold shared resources.  Maybe the
> LMF can make a tunable, on-the-fly decision how to use
> the context to "hook in" a profile to the shared stuff
> in the condy.  It would be very easy to wrap a trivial
> bit of bytecode around a method which does nothing
> except profile arguments and call the method on those
> arguments.  In this way most class structure generated
> by LMFs could be reused across compilation units,
> while still collecting contextual profile information.
>
> And when I say "shared stuff in condy", it could be
> either locally deduplicated stuff, or dynamically and
> globally deduplicated.
>
> Perhaps a well balanced design would manage to
> create distinct profile points for every distinct spot in the
> source code, while sharing everything else as globally
> as possible.  And telling the JIT about it, so that it
> never fails to inline the shared stuff into each distinctly
> profiled context.  Our current system approximates this.

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?

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

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

Note that the only risk is to point to another lambda in the source
file but with the same code...

Bernard

[1] http://mail.openjdk.java.net/pipermail/amber-dev/2018-March/002731.html


> — John