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