From Maxwell over Maxine to Graal VM, SubstrateVM and Truffle
airhacks.fm podcast with adam bien - Podcast autorstwa Adam Bien
Kategorie:
An airhacks.fm conversation with Thomas Wuerthinger (@thomaswue) about: Working on HotSpot, Sun started collaboration with Johannes Kepler University (JKU) in Linz, Java HotSpot is written in C++, "Array Bounds Check Elimination" for Java HotSpot Compiler, increased the performance by approx. 10%, the possibly most impactful student work ever, IdealGraphVisualizer (IGV): the graphical visualisation tool for HotSpot uses NetBeans visual library, IGV is also used for GraalVM, the Maxine Research VM at Sun Microsystems, Project Maxwell was renamed to Maxine, working at Sun's Menlo Park at Maxine, the circular optimization of Java leads to higher performance, the relation between Maxine and GraalVM, replacing the Maxine Compiler with Client HotSpot Compiler "transpiled" from C++ to Java, the C1X compiler, maxine was too ambitious, GraalVM just focusses on the compiler and makes it available for HotSpot, the Java compiler (javac) is written in Java, the quality of the JIT output is the first factor for good performance, HotSpot asks JIT to optimize "hot" methods, Maxine project is stil active, JVMCI, working on crankshaft compiler at Google with a team of 8 people, using Graal as polyglot environment, converting JavaScript to GraalIR was too complex, JavaScript is dynamic and GraalIR is typed, partial evaluation was inspired by PyPy, JavaScript interpreter was written in Java and is optimized by GraalVM, the frozen interpreters, the meta-circularity comes with the native image, a small JavaScript interpreter team implements recent JavaScript features, improving serverside ReactJS rendering performance with GraalVM, R, Ruby and Python are exectly the same integrated as JavaScript, Java is going to be interpreted in the same way as well, method inlining across language boundaries, Truffle is the intepreter API and comes with language-independent tooling, GraalVM is able to output bitcode instead of native code with LLVM, native image was used to compile the Graal compiler itself, the native image contains garbage collector, native image is considered "early adopters" technology, HotSpot mode is still 20% to 50% faster, G1 is going to be available on the native image as well, in future the performance of the AOT could vary +/-10% compared to JIT, polymorphic invocations could become faster on the native image / AOT, profile guided optimizations can be performed also ahead of time, new native images could learn from the past, the stability of AOT and JIT are similar, twitter already uses AOT for years, with Java you have the choice between AOT and JIT, unikernels could be supported by GraalVM in future, the GraalVM is hiring, Thomas Wuerthinger on twitter: @thomaswue