Hi, One of the goals of Jigsaw I read here: http://openjdk.java.net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques is: *Enable ahead-of-time, whole-program optimization techniques* - [..] The optimization techniques envisioned here include, but are not limited to: Fast lookup of both JDK and application classes; early bytecode verification; aggressive inlining of, *e.g.*, lambda expressions, and other standard compiler optimizations; construction of JVM-specific memory images that can be loaded more efficiently than class files; ahead-of-time compilation of method bodies to native code; and the removal of unused fields, methods, and classes. These kinds of techniques tend to work best when JDK and application code is analyzed together, prior to run time. [..]
- *Optimize existing code as-is* — It must be possible to apply the optimizer tool to existing code already packaged in traditional jar files, without changing those files. - *Actual optimizations* — As a proof of concept, provide at least two optimizations that deliver nontrivial performance benefits. My questions are: * What is the current state? Which techniques/optimizations are already implemented and available from the current ea JDK 9 or will be? * Are there any new insights/developments in this area? * I noticed in my JMH microbenchmark with parallelstream and lambda's that it runs slightly faster on 9_b85 compared to 8_u66. Could this be caused by more aggressive inlining of lambda's? * It seems to me that some compilation and optimization work is moved from runtime to link time, this will only be beneficial in limited cases, right? Are there obvious cases? * I don't really see why aggressive inlining and std optimizations can now be more effective. Because there will be less de-optimization events needed because of better predictability? Can in-lining now take place in two ways, between platform modules and application? Through interfaces? Thanks! -Jeroen
