On: We chose Java for our high-frequency trading appli...

[fh973]

That's covered in Java by escape analysis and allocation on the stack.

[bluestreak → fh973]

We have written a database in zero GC java and one thing I have not seen any evidence of "escape analysis".

   @State(Scope.Thread)
   @BenchmarkMode(Mode.AverageTime)
   @OutputTimeUnit(TimeUnit.NANOSECONDS)
   public class EscBenchmark {

       Rnd rnd = new Rnd();

       public static void main(String[] args) throws RunnerException {
           Options opt = new OptionsBuilder()
                   .include(EscBenchmark.class.getSimpleName())
                   .warmupIterations(5)
                   .measurementIterations(5)
                   .forks(1)
                   .addProfiler(GCProfiler.class)
                   .build();

           new Runner(opt).run();
       }

       @Benchmark
       public int testEscapeAnalysis() {
           int[] tuple = {0, 2}; // esc analysis? where are you?
           return tuple[rnd.nextPositiveInt() % 2];
       }
   }

And the output of GC profiler:

  Benchmark                                                     Mode  Cnt     Score     Error   Units
  EscBenchmark.testEscapeAnalysis                               avgt    5     8.234 ±   0.029   ns/op
  EscBenchmark.testEscapeAnalysis:·gc.alloc.rate                avgt    5  2647.216 ±   9.275  MB/sec
  EscBenchmark.testEscapeAnalysis:·gc.alloc.rate.norm           avgt    5    24.000 ±   0.001    B/op
  EscBenchmark.testEscapeAnalysis:·gc.churn.G1_Eden_Space       avgt    5  2643.140 ± 177.137  MB/sec
  EscBenchmark.testEscapeAnalysis:·gc.churn.G1_Eden_Space.norm  avgt    5    23.963 ±   1.613    B/op
  EscBenchmark.testEscapeAnalysis:·gc.count                     avgt    5   157.000            counts
  EscBenchmark.testEscapeAnalysis:·gc.time                      avgt    5   103.000                ms

[pdpi → bluestreak]

Scalar replacement has several requirements, and escape analysis is only part of the story. One of the restrictions with scalar replacement for arrays is that indexing has to be constant at JIT time, which your example clearly isn't.

[whizzter → pdpi]

The point would be that escape analysis could have proven that the array was not used outside of the function and allocated it fully on the stack, thus not providing any GC pressure. Scalar replacement isn't the point of interest really.

[hawk_ → bluestreak]

Which version of Java are you using? And what is Rnd? The class included with JDK is Random. We rely on escape analysis to elide such object creation for us and it works reasonably well. If something this trivial doesn't work for you, file bug with them. We have had success with that as well.

[bluestreak → hawk_]

This ran on Java 11. This isn't so much of an issue for us. We are trying to avoid allocations, even as trivial as those. There are other examples that allocated where they should not, for example this lambda will allocate.

  () -> System.out.println(1)

I lost hope in escape analysis quite frankly.

Rnd is something I have written because Java's Random is slow and clunky.

https://github.com/questdb/questdb/blob/master/core/src/main...

[pjmlp → bluestreak]

Escape analysis is very JVM implementation specific, but inline classes should finally sort it out.

[pdpi → fh973]

The JVM does scalar replacement, not stack allocation. The former is much more limited in functionality, and much more finicky. You also have about zero control over it, compared to, say, C# structs.