Condy for LambdaMetafactory?

[Tagir Valeev]

Oh, that's an interesting feature! Too bad, it works only when debugging
info is off, which is probably less than 1% of compiled Java code I've
seen. I've created a small sample to amuse people:

import java.util.function.IntSupplier;
import java.util.stream.IntStream;

public class Benchmark {
  private int compute() {
   IntSupplier s1 = () -> IntStream.range(0, 10000).map(v -> 1).sum();
   IntSupplier s2 = () -> IntStream.range(0, 10000).map(v -> 1).sum();
   IntSupplier s3 = () -> IntStream.range(0, 10000).map(v -> 1).sum();
   return s1.getAsInt() + s2.getAsInt() + s3.getAsInt();
  }

  private void measure() {
   int res = 0;
   // Warmup
   for (int i = 0; i < 20000; i++) {
    res += compute();
   }

   // Measurement
   long start = System.currentTimeMillis();
   for (int i = 0; i < 20000; i++) {
    res += compute();
   }
   long end = System.currentTimeMillis();
   System.out.println(res);
   System.out.println("Duration: " + (end - start) + "ms");
  }

  public static void main(String[] args) {
   new Benchmark().measure();
  }
}

With -g the measured time is about 1800ms, while without -g it's about
6ms. That's because when lambdas are deduplicated, type profile for
map() method is clean, and the whole stream can be inlined, and even
the loop could be likely replaced with a constant. When lambdas are
not deduplicated, this is not the case: type profile is polluted, and
the whole stream cannot be inlined. So, deduplication can actually
improve the performance, at least in such extreme cases.

By the way, while experimenting with this sample, I've noticed that
deduplication of this particular code is broken since Java 18 (the
code performs slowly both with and without -g, and reading the
bytecode confirms that no deduplication is done). Should I report, or
probably there's no interest in supporting this feature?


With best regards,

Tagir Valeev



On Mon, Oct 23, 2023 at 1:40 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 21/10/2023 19:59, John Rose wrote:
> > All I’m saying here is that sharing is not always a win. Sometimes the
> > opposite move, splitting and customization, is the performance win,
> > even though you have two copies of the code in the end.
>
> Something related to this topic, if we revisit this: currently javac
> deduplicates lambda bodies that are identical [1], so that only one BSM
> entry is generated (and then reused).
>
> The logic for doing that is a bit finicky, and it seems to go against
> the principle you outline above John. So, as we shift towards constant
> lambdas, perhaps there's a chance to look at this again.
>
> Cheers
> Maurizio
>
> [1] - https://bugs.openjdk.org/browse/JDK-8200301
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231024/d3055635/attachment-0001.htm>