3 ms·
Precisely what compilers do for a given flag varies by compiler and by version. There could potentially be issues with certain optimizations (unfortunately, the
by pron 7y ago
Precisely what compilers do for a given flag varies by compiler and by version. There could potentially be issues with certain optimizations (unfortunately, the OpenJDK VM does have undefined behavior, although we're attempting to gradually reduce it; the chance of a real problem due to undefined behavior certainly increases with the optimization level, as does the probability of a compiler bug), and there have been such issues in the past.
So while building OpenJDK with particular optimizations for your particular hardware might be worthwhile in some cases, it's not for the faint of heart, and it should be done with care and extensive testing. If you intend to deploy such a custom-built OpenJDK in production, you should strongly consider getting the JCK [1] (the Java TCK) and testing your build for conformance (for all the VM configurations you'll use: GC choice, compiler choice etc.).
A safer and easier way to get "free" performance speedups is to use the most recent JDK (currently 13).
[1]: http://openjdk.java.net/groups/conformance/JckAccess/ http://openjdk.java.net/groups/conformance/JckAccess/
- danwills 7y agoI wonder whether Gentoo might have an edge here (even in general beyond just jdk) since nearly everything on the system is built with the local CPU as the optimisation target? It certainly reduces the need to not be 'feint of heart' to build things too as it's part of business-as-usual. Whether Gentoo itself requires one to not be feint of heart, is definitely an open question!
- saagarjha 7y ago> unfortunately, the OpenJDK VM does have undefined behavior, although we're attempting to gradually reduce it Is it a goal to remove undefined behavior completely? Because I seem to recall certain architectural decisions being completely reliant on undefined behavior, such as signal handlers as implicit null checks…
- chrisseaton 7y agoYou can write these little architectural parts in assembly rather than C, to avoid having to write undefined behaviour.
- saagarjha 7y agoDoes the JVM use assembly for this? I’d expect writing all of the VM code that handles Java objects in assembly for each platform would be a bit difficult, and I’m not sure I saw enough assembly files in the project for this…
- chrisseaton 7y agoNo I mean it is an option available to avoid undefined behaviour, not that this is what the JVM does. But moving more of the implementation of the JVM (or all of it!) to Java is the real solution to all this in my opinion.
- saagarjha 7y ago> No I mean it is an option available to avoid undefined behaviour, not that this is what the JVM does. Ah. > But moving more of the implementation of the JVM (or all of it!) to Java is the real solution to all this in my opinion. And what, ship a Graal binary to cut the bootstrapping/startup step?
- chrisseaton 7y agoYes, rewrite all of the JVM into Java and ship an AOT-compiled binary.
- pron 7y agoBTW, there's much more assembly code in OpenJDK than you'd find by looking for assembly files. There's a lot of code (all of the interpreter, for example) that's generated at startup time, and written in assmebly as a C++ DSL. E.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/templateTable_x86.cpp https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x... and https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x...
- pron 7y agoI don't know if there is such a goal, but we certainly try to reduce undefined behavior in OpenJDK; e.g. https://bugs.openjdk.java.net/browse/JDK-8233144 https://bugs.openjdk.java.net/browse/JDK-8233144