4 ms·
Scalar replacements (as currently implemented in Java) does not work in real-world programs. Well-written code does not need it. Poorly written code can not tr
by altfredd 5y ago
Scalar replacements (as currently implemented in Java) does not work in real-world programs.
Well-written code does not need it. Poorly written code can not trigger it, because the JIT is too dumb and isn't getting better.
There is no sane test to determine whether a piece of code will be inlined in Java. In practice anything more complex than byte array is unlikely to be inlined. Even built-in ByteBuffers aren't! Meanwhile Go compiler treats Go slices just as nicely or better than arrays.
- deleted 5y ago[deleted]
- pjmlp 5y agoWhich JIT? There are plenty of them to choose from across Java implementations.
- native_samples 5y agoThe JIT is getting better. Major escape analysis upgrades are a big part of where Graal (a drop-in replacement for the HotSpot JIT) gets its performance boosts. EA definitely does work well there because Truffle depends on escape analysis and scalar replacement very heavily. GraalVM CE is better than regular HotSpot at doing it and GraalVM EE is even better again.
- altfredd 5y agoGraal effort is over 10 years old. Jaotc, — Graal's sole mainstreamed part, — has been recently removed from OpenJDK in 17th release, and Oracle says [1], that they are "considering the possibility of using C2 for ahead-of-time" 1: https://mail.openjdk.java.net/pipermail/discuss/2020-November/005634.html https://mail.openjdk.java.net/pipermail/discuss/2020-Novembe...
- kaba0 5y agoIt’s almost as if graal and openjdk are separate projects with different use cases. Also, they are not competing (in the usual meaning) since both are developed by Oracle.