JIT Versus AOT: Unity And Conflict of Dynamic and Static Compilers (JavaOne 2017 edition)
•
3 gefällt mir•1,511 views
Java has been constantly criticized for poor performance ever since its inception, but not as much in recent years. Thanks to optimizing dynamic native code compilers, Java performance today is very close to the performance of low-level languages such as C/C++. Along with dynamic compilers, static compilers for Java have been evolving as well, so there is still no clear winner between these two approaches. It is not a surprise that an AOT compiler is finally going to appear in Java 9 via JEP-295. This session’s speaker would like to dispel common myths about the old dispute over whether dynamic or static compilation is better, show that both approaches have their strengths and weaknesses, and explain why the future is the hybrid approach.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie JIT Versus AOT: Unity And Conflict of Dynamic and Static Compilers (JavaOne 2017 edition)
Ähnlich wie JIT Versus AOT: Unity And Conflict of Dynamic and Static Compilers (JavaOne 2017 edition) (20)
Mehr von Nikita Lipsky
Mehr von Nikita Lipsky (19)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
JIT Versus AOT: Unity And Conflict of Dynamic and Static Compilers (JavaOne 2017 edition)
- 1. JIT vs. AOT: Unity And Conflict of Dynamic and Sta:c Compilers for Java 1 Nikita Lipsky Excelsior LLC
- 2. 2
- 3. Once upon a time, when C++ was new and cool, +++++++++ 3
- 4. Once upon a time, when C++ was new and cool, +++++++++ 4
- 5. Once upon a time, when C++ was new and cool, all compilers were static 5
- 6. Until into this world came… Java 6
- 7. Until into this world came… Java
- 11. JIT vs. AOT: Agenda • Myths around Java AOT • Java AOT challenges and advantages • Performance: – JIT vs. AOT compiler op:miza:ons comparison • JIT and AOT in various fields of use: – client-side, server-side, embedded, IOT, mobile 11
- 12. Nikita Lipsky • Excelsior JET project ini:ator – 16+ years of contribu:ons – compiler engineer – team lead – product lead – etc. • TwiSer: @pjBooms • Excelsior JET team blog: hSps://www.excelsiorjet.com/blog 12
- 13. 13
- 14. Who needs Java AOT 14 Кто знает про Excelsior JET?Кто знает про Excelsior JET?
- 19. Myth 3. AOT = Small EXE • What about thousands of standard classes? • Who will collect the garbage? • What about reflec:on? 19
- 21. Non-standard Class Loaders • Override the default reference resolu:on logic • Unique namespaces • Dependency management frameworks – OSGi: Felix, Equanox to solve JAR hell problem • Java EE servers, Eclipse RCP, plugin architectures 21
- 22. Non-standard Class Loaders How to compile such classes sta:cally? • Compile each class in isola:on – Bad for performance • Reproduce reference resolu:on logic of popular class loaders – Does not work for arbitrary class loaders 22
- 23. Non-standard Class Loaders Custom classloaders support scheme: • At AOT compile :me: – class reference resolu:on according classloaders’ logic • At applica:on run :me: – Each precompiled class is assigned to the classloader instance Known to work for Eclipse RCP and Tomcat Web apps 23
- 24. Non-standard Class Loaders Custom classloaders support scheme: • At AOT compile :me: – class reference resolu:on according classloaders’ logic • At applica:on run :me: – Each precompiled class is assigned to the classloader instance Known to work for Eclipse RCP and Tomcat Web apps 24
- 27. Applica:on Code Protec:on • Bytecode emiSed by javac is extremely easy to decompile almost to original source Proof: hSp://bytecodeviewer.com/ • Reflec:on makes name obfusca:on labor- consuming and error prone, hinders code maintenance • Possible to guess what obfuscated code does References to JDK classes remain intact 27
- 28. Applica:on Code Protec:on • Na:ve machine code can only be effec:vely disassembled, but not decompiled • Applica:on structure not deduc:ble from disassembler output • Aggressively op:mized na:ve code only remotely resembles original 28
- 32. AOT IS Faster! 1. Iden:fy code that gets executed on startup 2. Place it at the beginning of the executable 3. Preload the en:re “startup segment” sequen:ally 32
- 33. 1.6 2.5 13.3 5 2.5 2.7 14 5.7 0.1 1.7 4 1.9 0.9 2.2 5 2.2 0 2 4 6 8 10 12 14 16 FeedDaemon FeedReader RSSOwl (JRE) RSSOwl (JET) Startup :me on HDD (sec) Cold (AC) Cold (baSery) Warm (AC) Warm (baSery) 33
- 34. 0.1 1.7 4.9 2.4 1.3 2.1 6.3 3.4 0.05 1.6 3.8 1.6 1 2 6.4 3.3 0 1 2 3 4 5 6 7 FeedDaemon FeedReader RSSOwl (JRE) RSSOwl (JET) Startup :me on SSD (sec) Cold (AC) Cold (baSery) Warm (AC) Warm (baSery) 34
- 35. Performance 35
- 40. Compiler Op:miza:ons – Constant propaga:on – Dead code elimina:on – Common subexpression elimina:on – Inline subs:tu:on – Method specializa:on – Loop unrolling – Loop versioning – Loop-invariant code mo:on – Tail recursion elimina:on – Call devirtualiza:on – On-stack alloca:on and explosion of objects – Scalar replacement – Run:me checks removal – Synchroniza:on removal – Op:mal code selec:on – Instruc:on scheduling – Op:mal register alloca:on – etc. 40
- 42. Call Devirtualiza:on Precondi:on for subsequent inline subs:tu:on • Class hierarchy analysis Method not overridden => non-virtual call • Type inference new T().foo(); // Non-virtual // call of T.foo() • Profile guided 42
- 43. A a; … a.foo(); if (RT_Type(a) in CHA-set) { inlined body of foo() } else { a.foo(); } Idea: method not overriden in subclasses => non-virtual call Class Hierarchy Analysis (CHA) 43 compiled to
- 45. Type Analysis A a = b ? new B() : new C(); a.foo();// non-virtual call too, because // B, C extend A and do not override A.foo 45
- 46. Type Analysis A a = b ? bar() : baz(); … a.foo(); If bar() only returns new B, baz() only returns new С, then a.foo() is non-virtual and can be inlined 46
- 48. Global Analysis • Analyses all methods of the program, compu:ng useful info about each – whether a method always returns new T(); – whether an argument of a method does not escape to a shared memory – etc. • The info is then used during op:miza:on of methods 48
- 49. Stack Alloca:on of Objects • All Java objects are supposed to reside in dynamic memory – on the Java heap • But, most objects are small and temporary • It is desirable to allocate them on the stack Escape analysis determines whether a locally created object is not reachable aeer the method returns 49
- 50. Example for (Object o: getCollection()) { doSomething(o); } 50
- 51. Example Iterator iter = getCollection().iterator(); while (iter.hasNext()) { Object o = iter.next(); doSomething(o); } 51
- 52. Example Suppose the analysis has shown that getCollection() always returns new ArrayList() ArrayList list = getCollection(); Iterator iter = list.iterator(); while (iter.hasNext()) { Object o = iter.next(); doSomething(o); } 52
- 53. Example ArrayList list = getCollection(); ArrayList.Itr iter = new ArrayList.Itr(list); while (iter.hasNext()) { Object o = iter.next(); doSomething(o); } 53
- 54. Example ArrayList list = getCollection(); ArrayList.Itr iter = onStack Itr(); iter.this$0 = list; iter.cursor = 0; iter.size = list.elemData.length; while (iter.hasNext()) { Object o = iter.next(); doSomething(o); } 54
- 55. Example ArrayList list = getCollection(); ArrayList.Itr iter = onStack Itr(list); iter.this$0 = list; iter.cursor = 0; iter.size = list.elemData.length; while (iter.cursor < iter.size) { int index = iter.cursor++; Object o = iter.this$0.elemData[index]; doSomething(o); } 55
- 56. Example ArrayList list = getCollection(); int cursor = 0; int size = list.elemData.length; while (cursor < size) { Object o = list.elemData[cursor++]; doSomething(o); } 56
- 57. Example ArrayList list = getCollection(); int size = list.elemData.length; for (int i = 0; i < size; i++) { doSomething(list.elemData[i]); } 57
- 58. Analysis & Op:miza:ons… • …are oeen quite complicated • …require itera:ve re-computa:on • …, if global, depend on the enBre program 58
- 59. Analysis & Op:miza:ons… • …are oeen quite complicated • …require itera:ve recomputa:on • …, if global, depend on the enBre program Can a JIT compiler afford all or any of that?
- 60. Analysis & Op:miza:ons… • …are oeen quite complicated • …require itera:ve recomputa:ons • …, if global, depend on the enBre program Can a JIT compiler afford all or any of that? 60
- 61. Analysis & Op:miza:ons… • …are oeen quite complicated • …require itera:ve recomputa:ons • …, if global, depend on the enBre program Can a JIT compiler afford all or any of that?
- 62. Dynamic Op:miza:ons • Profiling and selec:ve compila:on • Inline subs:tu:on based on execu:on profile • Hot execu:on traces op:miza:on • Op:mal instruc:on selec:on
- 70. Server side • CPU :me in the cloud costs money • Aeer some :me, execu:on profile of a server app stabilizes in many cases • Why not pass it over to the AOT compiler? 70
- 71. AOT on the Server side • Stable performance and predictable latency – no code de-op:miza:ons occur at run-:me • Work at full speed right from the start – good for load balancing • BeSer startup :me – good when many servers (re-)start simultaneously • S:ll protects the code from decompila:on 71
- 73. Mobile • JVM on Mobile: – Plaxorm classes – Memory Manager and GC – Reflec:on – JIT Compiler What is missing? 73
- 74. Mobile • JVM on Mobile: – Plaxorm classes – Memory Manager and GC – Reflec:on – JIT Compiler What is missing? 74
- 75. Mobile • JVM on Mobile: – Plaxorm classes – Memory Manager and GC – Reflec:on – JIT Compiler What is missing? 75
- 76. Mobile • JVM on Mobile: – Plaxorm classes – Memory Manager and GC – Reflec:on – JIT Compiler What is missing? 76
- 77. Mobile • JVM on Mobile: – Plaxorm classes – Memory Manager and GC – Reflec:on – JIT Compiler What is missing? 77
- 78. Mobile • JVM on Mobile: – Plaxorm classes – Memory Manager and GC – Reflec:on – JIT Compiler What is missing? 78
- 79. Mobile • JVM on Mobile: – Plaxorm classes – Memory Manager and GC – Reflec:on – JIT Compiler Charger! 79
- 87. Sta:c compila:on of Java apps: 87 Possible Preserving all Java features Conclusion
- 88. Sta:c compila:on of Java apps: 88 Possible Preserving all Java features Useful in many aspects Conclusion
- 91. Q & A Nikita Lipsky, Excelsior nlipsky@excelsior-usa.com twitter: @pjBooms Team blog: https://www.excelsiorjet.com/blog 91