deduplicating lambda methods

[Liam Miller-Cushon]

Hmm, if I compile Types.java by itself I'm seeing deduplication occur.

I collected some statistics from Google's codebase.
In compilation units with >1 lambda, 12.8% of lambdas were deduplicated.

That number doesn't tell the whole story about whether deduplication is
useful
in practice, but if nothing else it lets us measure the relative
improvement from
changes to the deduplication logic.

I also investigated deduplicating lambdas that contain local variable
declarations.
The implementation uses the approach I mentioned earlier: it keeps a record
of variable declarations visited during diffing and hashing, recognizes
subsequent
uses of those variables, and treats them as equal / hashes them to a stable
value.
Lambda parameters are now handled using the same logic as locals, instead of
as a special case.

Handling locals increased the number of deduplicated lambdas by 1.3%.
I don't think that's enough to justify adding a lot of complexity here, but
the
patch actually simplifies some of the existing logic.

Here's the webrev:
http://cr.openjdk.java.net/~cushon/lambdadedup2/webrev.00/


On Fri, Mar 30, 2018 at 10:03 AM Vicente Romero <vicente.romero at oracle.com>
wrote:

> The stats application is able to see, and report, the difference in the
> class files with the reproductor you sent, but it seems like there is no
> lambda deduplication when Types is compiled. I have been checking the
> class file obtained for Types.CaptureScanner and there is no
> deduplication there, two lambda methods are generated. This will need
> further research,
>
> Vicente
>
> On 03/30/2018 09:12 AM, B. Blaser wrote:
> > On 27 March 2018 at 19:33, Vicente Romero <vicente.romero at oracle.com>
> wrote:
> >>
> >> On 03/27/2018 12:58 PM, Brian Goetz wrote:
> >>> It looks like there were no changes in the outcome, perhaps because
> there
> >>> were no within-file duplications in the JDK.  (Which I believe.)  A
> more
> >>> streams/Rx/CompletableFuture-heavy codebase would likely see an
> improvement.
> >>
> >> right, no difference :(, let's see what happens with Liam's numbers :)
> >>
> >> Vicente
> > I perhaps found at least one trivial lambda duplicate in the JDK (javac)
> here:
> >
> >
> http://hg.openjdk.java.net/jdk/jdk/file/814bd31f8da0/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#l450
> >
> > I tried to reproduce it like this (is that right?):
> >
> > import java.util.List;
> > import java.util.Set;
> >
> > public class Test {
> >      class CaputureScanner extends SimpleVisitor {
> >          public Void visitClassType(Type.ClassType t, Set<Type> seen) {
> >              if ( t.isCompound() ) {
> >                  directSupertypes(t).forEach(s -> visit(s, seen));
> >              } else {
> >                  t.allparams().forEach(ta -> visit(ta, seen));
> >              }
> >              return null;
> >          }
> >      }
> >      public static class SimpleVisitor {
> >          public Void visit(Type t, Set<Type> seen) { return null; }
> >      }
> >      public static class Type {
> >          public boolean isCompound() { return false; }
> >
> >          public static class ClassType extends Type {
> >              public List<Type> allparams() { return null; }
> >          }
> >      }
> >      public List<Type> directSupertypes(Type t) { return null; }
> > }
> >
> > which is correctly de-duplicated.
> >
> > But stats don't show any difference, are they missing something?
> >
> > Bernard
>
>