370 likes | 458 Views
P ARALLEL P ROCESSING I NSTITUTE · F UDAN U NIVERSITY. Opencj: A research Java static compiler based on Open64 ( s ponsor by HP). Keqiao Yang, Zhemin Yang, Zhiwei Cao Zeng Huang, Di Wang, Min Yang, Binyu Zang Fudan University. Outline. Motivation Design & Implementation
E N D
PARALLEL PROCESSING INSTITUTE · FUDANUNIVERSITY Opencj: A research Java static compiler based on Open64 (sponsor by HP) Keqiao Yang, Zhemin Yang, Zhiwei Cao Zeng Huang, Di Wang, Min Yang, BinyuZang Fudan University
Outline Motivation Design & Implementation Evaluation Future work
The popularity of Java 20.299%
Java! Write Once Run Anywhere How to further improve Java runtime performance? Architecture neutral Simplified memory management Security and Productivity ……
Our Research • Leverage the synergy between static and dynamic optimizations • Dynamic environment while leveraging static benefits • Finding performance opportunities before runtime • Static annotation to help runtime optimization
Opencj It is our first milestone in the whole project Develop based on Open64 Takes Java source files or Class files as input Outputs executable code for Linux/IA32&x86-64 Compilation process is similar to compiling C/C++ applications
Outline Motivation Design & Implementation Evaluation Future work
Design Overview of Opencj Migrate frontend of gcj into Open64
Java exception handling • Similar to C++ exception, but has some differences, such as • runtime exceptions: a/0, NullPointerException • No “catch-all” handler used in C++ • “finally” mechanism, makes Java exception more complex than C++ • The key point of Java exception handling is to record the relationship among try/catch/finally blocks.
Devirtualization Easy to reuse code for programmers but hard to analyze for compiler Resolve java virtual function call to promote indirect call into direct call Class hierarchy analysis and Rapid type analysis Devirtualization is implemented at IPA phase Many optimizations can benefit from this transformation In SciMark 2.0 Java benchmark test, it can resolve all 21 user defined virtual function calls.
Synchronization elimination • Based on Escape Analysis • Flow-insensitive & interprocedural analysis • Connection Graph: captures the connectivity relationship among objects and object references. • Easily determine whether an object is local to a thread. • If a synchronized object is local to a thread, the synchronized operation can be removed
Building connect graph Only five kinds of statements 1. p = new P() 2. p = return_new_P() 3. p = q 4. p = q.f 5. p.f = q
Analysis process • Intra-procedural analysis • Check every call graph node to find out whether there is a synchronized call in a PU • Set initial escape state of each reference node • Inter-procedural analysis • Start from main function and traverse the call graph in depth-first order • Pass escape states between caller and callee
Example 1 GlobalEscape OutEscape OutEscape GlobalEscape NoEscape
Example 1 GlobalEscape NoEscape GlobalEscape NoEscape
Example2 GlobalEscape ArgEscape ArgEscape GlobalEscape NoEscape
Example2 GlobalEscape NoEscape GlobalEscape NoEscape
Array bounds check elimination Array bounds check to guarantee Java type-safe execution Prevent many useful code optimizations since array bounds check may raise exceptions Fully elimination: if the check never fails Partial elimination: whenever possible, moves bounds check out of loops
Fully redundant check elimination 0<=i1<100 jc1 Example
Partial elimination Adopting loop versioning technique to guarantee the exception semantic for Java Set trigger conditions before and after the optimized loop
Checks elimination of ABCE Total: the total number checks in the test case PRCE: the number of Partial Redundant Check Elimination FRCE: the number of Fully Redundant Check Elimination ABCE: FPCE+PRCE 28.4% speedup in Scimark2 test, lower than we expected
Outline Motivation Design & Implementation Evaluation Future work
Performance gap between Java & C higher is better • opencj -O3 -IPA -fno-bounds-check • opencc -O3 -IPA • gcj -O3 -fno-bounds-check -funroll-loops • gcc -O3 -funroll-loops
Static compilation vs JIT higher is better • Comparing two Java running modes. • Running in JVM • Running executable file directly
Static compilation vs JIT lower is better • JDK 1.6 is best except mpegaudio • More analysis work need to do.
Outline Motivation Design & Implementation Evaluation Future work
Future Trends – for Java • Where is Java headed with its dynamic optimization framework: • Exploring opportunities to achieve performance parity with native code • Online profiling mechanisms and feedback-directed optimizations becoming mainstream • …
Java advantages • Several studies show that Java could potentially be faster than C/C++ for some reasons: • C/C++ Pointers make optimization difficult • It is easier to do memory management in Java than C/C++ as Java only allocates memory through object instantiation. So Java garbage collectors can achieve better cache coherence • Dynamic compilation of Java can use additional information available at run-time to optimize code more effectively.
Future of Opencj • Opencj will achieve better runtime performance by using JVM as the execution environment • Static annotation with annotation-aware JIT - Runtime IPA • Using just-in-time compiler - Apply more effective optimizations by profiling run-time information • Using garbage collection - Better performance due to cache coherence • There are three steps in our schedule
Discussion Shin is the leader of this project Q&A