deduplicating lambda methods

Vicente Romero vicente.romero at oracle.com
Mon Apr 2 13:44:24 UTC 2018


Hi Liam,

On 03/30/2018 11:03 PM, Liam Miller-Cushon wrote:
> 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/ 
> <http://cr.openjdk.java.net/%7Ecushon/lambdadedup2/webrev.00/>
>

thanks for the further development, the change looks good to me,
Vicente

>
> On Fri, Mar 30, 2018 at 10:03 AM Vicente Romero 
> <vicente.romero at oracle.com <mailto: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 <mailto: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
>



More information about the amber-dev mailing list