Hacker News Reader

Hacker News

Comment by earenndil | Hacker News Reader

Parent Full thread

earenndil

> [-Ofast will] be "faster" but completely break applications

Except for the jvm, apparently. And everything else I've tried it with.

> It also suggests using omit frame pointer which destroys debugability.

Which is completely useless except for jvm developers.

> As I understand it the arch that Java is compiled with is not the same as the one that gets used for JIT compiling.

The performance of the compiler itself matters, not just the performance of the generated code, because, since it's a JIT, compiler code continues to run.

View on HN

The Hotspot JIT reads the CPU configuration at runtime to choose which optimizations are best or which instruction extensions are available.

Right, but the OpenJDK VM (HotSpot) uses three JITs -- C1, C2 and Graal -- and two of them are written in C++, so C++ compiler flags could affect the performance of the JIT compilers, although not of the code they generate. Because the performance of the emitted code is far more important than the performance of the compiler, I doubt that will make a difference, but there are other important parts of the OpenJDK VM that are written in C++ and whose performance might be affected, most notably the GCs.

I would like gcc to compile OpenJDK correctly for AArch64 before I started messing with any performance settings.

I agree that messing with compiler flags is not the most effective use of time and risk as fat as improving the JDK's performance goes.

That's great for the Java code being JITed, but does nothing for the JIT compiler itself, or the garbage collectors, or any other runtime components that are written in C or C++ and compiled (and optimized) ahead of time.

Yeah, I suspect a good chunk of the performance improvement is related to GC performance improvement. The netty benchmark with pooled buffers compared to unpooled buffers hints at that (although I don't know for sure).

That doesn't help the performance of the runtime code, which is C++ or AOT-compiled Java.

> omit frame pointer which destroys debugability.

IIRC frame pointers were necessary for a Linux flame graph tool I used on the JVM.

Based on `perf`? If so, try passing `--call-graph dwarf` in your `perf record` invocation. Then things should work fine despite lack of frame pointers.

Reply on news.ycombinator.com