deduplicating lambda methods
john.r.rose at oracle.com
Sat Mar 3 01:57:10 UTC 2018
On Mar 2, 2018, at 5:17 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Is there any trickiness with capturing lambdas? I don't think so -- I think we can merge these too, although I suspect the return on that effort is lower. I'll bet the most common case is lambdas like e -> e, x -> System.out.println(x), etc.
A good extension to Liam's proposal, that should arise naturally
from his AST matching work, would be to recognize the top ten
(or so) AST patterns, like the above and also e -> k and k::m
(for constants k). The desugared methods for these a trivial,
and as such should deduplicated *across compilation units*.
They could be defined as part of this work as new members
of the LMF class.
Another good extension to consider is to evaluate the body
of a capturing (but non-constant) lambda and detect whether
the lambda capture point can be moved out of a loop.
That's tricky because you don't want to trigger a capture
for a zero-trip loop. But it's worthwhile because users
frequently write loop-invariant lambdas without realizing it.
(The latter problem is one of de-duplication for duplicates
created by loop iterations. So it's not de-duplication in
the same sense. But it does require an AST analysis
of a lambda body, in context of a containing loop.)
More information about the amber-dev