Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

JIT - the hidden gem of the JVM

408 visualizaciones

Publicado el

Just-in-time compiler is enabled by default in the JVM and it does a lot of work to make your Java applications to execute faster. Let's look into optimizations that JIT does at run time, explore the JIT log and try to shape our code for better JIT performance.

Publicado en: Tecnología
  • Sé el primero en comentar

JIT - the hidden gem of the JVM

  1. 1. 01
  2. 2. Let's start! 02
  3. 3. What's in this presentation What is JIT? What does it do? How to tune it? Do we need to tune it? • • • • 03
  4. 4. JIT 04
  5. 5. JIT Just­In­Time compilation Compiled when needed Maybe immediately before execution ...or when we decide it's important ...or never? • • • • • 05
  6. 6. JVM 06
  7. 7. Mixed­mode Interpreted Bytecode­walking Artificial stack machine Compiled Direct native operations Native register machine The Hotspot JVM uses mixed­mode JIT First interpreted, then compiled • • • • • • • • 07
  8. 8. Bytecode execution 08
  9. 9. Profiling Gather data about code while interpreting Invariants (types, constants, nulls) Statistics (branches, calls) Use that information to optimize Educated guess It decides when to compile to native code, through profiling It looks at which methods are called, at loops, at locks The JVM guys called it "the shape of code" • • • • • • • • 09
  10. 10. Optimization Method inlining Loop unrolling Lock coarsening/eliding Dead code elimination Duplicate code elimination Escape analysis ... • • • • • • • 10
  11. 11. Inlining Combine caller and callee into one unit e.g. based on profile Perhaps with a guard/test Optimize as a whole More code means better visibility • • • • • 11
  12. 12. Inlining 12
  13. 13. Inlining 13
  14. 14. Inlining 14
  15. 15. Loop unrolling Works for small, constant loops Avoid tests, branching Allow inlining a single call as many • • • 15
  16. 16. Loop unrolling 16
  17. 17. Loop unrolling 17
  18. 18. Lock coarsening 18
  19. 19. Lock coarsening 19
  20. 20. Lock coarsening 20
  21. 21. Lock eliding 21
  22. 22. Lock eliding 22
  23. 23. Lock eliding 23
  24. 24. Escape analysis 24
  25. 25. Escape analysis 25
  26. 26. Escape analysis 26
  27. 27. Escape analysis Escape Analysis is a bit "flaky" on older Hotspot versions Much better in JRockit and later Hotspot versions • • 27
  28. 28. Call site The place where you make a call Monomorphic ("one shape") Single target class Bimorphic ("two shapes") Polymorphic ("many shapes") Megamorphic ("you're screwed") • • • • • • 28
  29. 29. Call site A call site of a function (subroutine) is a line in the code, which calls (or may call, through dynamic dispatch) a function. A call site passes zero or more arguments to the function, and receives zero or more return values. 29
  30. 30. Example.java 30
  31. 31. Compilers 31
  32. 32. Hotspot client mode (C1) inlines, less aggressive Fewer opportunities to optimize server mode (C2) inlines aggressively Based on richer runtime profiling tiered mode • • • • • 32
  33. 33. C1 Compiler Fast startup No profiling • • 33
  34. 34. C2 Compiler Profile to find "hot spots" Call sites Branch statistics Profile until 10k calls Inline mono/bimorphic calls Other mechanisms for polymorphic calls • • • • • • 34
  35. 35. Tiered Compilation ‐XX:+TieredCompilation Multiple tiers of interpretation Level 0 (interpreted) Level 1 (C1, no profiling) Level 2 (C1, basic profiling) Level 3 (C1, full profiling) Level 4 (C2) • • • • • • • 35
  36. 36. Monitoring JIT Dozens of flags Reams of output Always evolving • • • 36
  37. 37. Accumulator.java 37
  38. 38. Run Accumulator.java 38
  39. 39. Print compilation ‐XX:+PrintCompilation Print methods as they compile Class + name + size • • • 39
  40. 40. JIT debug 40
  41. 41. JIT debug 41
  42. 42. Zombies 42
  43. 43. Optimisitic compilers Assume profile is accurate Aggressively optimize based on profiling information Bail out if we're wrong ...and hope that we're usually right • • • • 43
  44. 44. Optimisitic compilers The way JVM works is based on OPTIMISTIC compilers It assumes that the profile of the code is always accurate and will base optimize based on this profile What if we are wrong? We need to be able to bail out... What can change? Different branches in the interpreter, new classes loaded, etc. • • • • 44
  45. 45. Deoptimization Bail out of running code Monitoring flags describe process "uncommon trap" ­ something's changed "not entrant" ­ don't let new calls enter "zombie" ­ on its way to deadness • • • • • 45
  46. 46. Deoptimization Uncommon trap ­> there was a mistake and JIT needs to reanalyze the system Non­entrant ­> no thread can enter this code anymore Zombie ­> code that will never be used • • • 46
  47. 47. Deoptimization Example: Generally the server compiler makes aggressive inlining decisions of non­final methods. As long as the inlined method is never overridden the code is correct. When a subclass is loaded and the method overridden, the compiled code is broken for all future calls to it. The code gets declared "non entrant" (no future callers to the broken code), but sometimes existing callers can keep using the code. In the case of inlining, that's not good enough; existing callers' stack frames are "deoptimized" when they return to the code from nested calls (or just if they are running in the code). 47
  48. 48. No JIT at All? Code is too big Code isn't called enough • • 48
  49. 49. Other interesting flags b    Blocking compiler (always set for client) *    Generating a native wrapper %    On stack replacement (where the compiled code is running) !    Method has exception handlers s    Method declared as synchronized n    Method declared as native 01. 02. 03. 04. 05. 06. 49
  50. 50. More on JIT debug 50
  51. 51. Print inlining ‐XX:+UnlockDiagnosticVMOptions   ‐XX:+PrintInlining Display hierarchy of inlined methods Include reasons for not inlining After compilation, we go deeper to figure out how the JVM decides inlining We use new flag to show the hierarcy of methods which get inlined The  UnlockDiagnosticVMOptions  is required when using PrintInlining  and other flags which enable debug output • • • • • • 51
  52. 52. No inline? 52
  53. 53. Why? 53
  54. 54. Why? The "add" method get "jitted", but not inlined, because there is nothing to inline. The "+" operation is native and the "hot" code is not "hot" enough to get other methods inlined. 54
  55. 55. New class 55
  56. 56. Inline output 56
  57. 57. Intrinsic Known to the JIT Don't inline bytecode Do insert "best" native code e.g. kernel­level memory operation e.g. optimized  sqrt  in machine code • • • • • 57
  58. 58. Common intrinsics String#equals All of  Math  methods System.arraycopy Object#hashCode Object#getClass sun.misc.Unsafe  methods • • • • • • 58
  59. 59. Tuning inlining ‐XX:+MaxInlineSize=35 Largest inlinable method (bytecode) ‐XX:+InlineSmallCode=# Largest inlinable compiled method ‐XX:+FreqInlineSize=# Largest frequently­called method... • • • • • • 59
  60. 60. Tuning inlining ‐XX:+MaxInlineLevel=9 How deep does the rabbit hole go? ‐XX:+MaxRecursiveInlineLevel=# Recursive inlining • • • • 60
  61. 61. More JIT logging ‐XX:+UnlockDiagnosticVMOptions ‐XX:+TraceClassLoading ‐XX:+LogCompilation   �  ‐XX:+PrintCodeCache   �  ‐XX:+PrintCodeCacheOnCompilation • • • 61
  62. 62. More JIT logging ‐XX:+PrintAssembly ‐XX:+PrintOptoAssembly • • 62
  63. 63. Code cache size ‐XX:ReservedCodeCacheSize=#• 63
  64. 64. Demo: JIT 64
  65. 65. Demo: JitWatch 65
  66. 66. Hmm... Can't we just compile all code before JVM starts? Can we cache compiled code and make JVM start faster? • • 66
  67. 67. AOT IBM JDK Azul Zing Excelsior JET ... • • • • 67
  68. 68. AOT in HotSpot 68
  69. 69. AOT in HotSpot 69
  70. 70. Conclusion 70
  71. 71. Take­aways JIT compiler is on and works well by default JIT compiler transforms code based on profiling information it collects while application is running It's worth tuning for frameworks/high­performance/low­latency scenarios Method size and call frequency matters • • • • 71
  72. 72. Reading material 72
  73. 73. References I https://wiki.openjdk.java.net/display/HotSpot/LogCompilation+overview http://www.oracle.com/technetwork/articles/java/architect­evans­pt1­ 2266278.html https://gist.github.com/chrisvest/2932907 http://blog.joda.org/2011/08/printcompilation­jvm­flag.html • • • • 73
  74. 74. References II https://blog.codecentric.de/en/2012/07/useful­jvm­flags­part­2­flag­ categories­and­jit­compiler­diagnostics/ http://www.insightfullogic.com/2014/May/12/fast­and­megamorphic­ what­influences­method­invoca/ http://psy­lob­saw.blogspot.co.uk/2013/05/using­jmh­to­benchmark­ multi­threaded.html http://www.slideshare.net/iwanowww/jitcompiler­in­jvm­by • • • • 74
  75. 75. References III https://vimeo.com/197377385 http://www.slideshare.net/MonicaBeckwith/the­performance­engineers­ guide­to­hotspot­justintime­compilation https://www.infoq.com/articles/OpenJDK­HotSpot­What­the­JIT https://www.infoq.com/news/2016/10/AOT­HotSpot­OpenJDK­9 • • • • 75
  76. 76. Books 76
  77. 77. Java Performance 77
  78. 78. Java Performance Companion 78
  79. 79. Java Performance: The Defenetive Guide 79
  80. 80. Java Performance And Scalability 80
  81. 81. People to follow Kirk Pepperdine Monica Beckwith Alexey Shipilev Sergey Kuksenko Vladimir Ivanov and many others • • • • • • 81
  82. 82. OpenJDK source code http://hg.openjdk.java.net /jdk8u/jdk8u/hotspot /file/e765322578aa/src/share/vm/opto • • • 82
  83. 83. Questions? 83
  84. 84. Upcoming trainings 84
  85. 85. JVM internals & perf. tuning 85
  86. 86. JVM internals & perf. tuning http://devchampions.com/training/jvm/ Riga, 18th­19th of May, 2017 15% discount to JUG members, use JUG_LV code • • • 86
  87. 87. Effective Coding Principles in Java 8 87
  88. 88. Effective Coding Principles in Java 8 http://devchampions.com/training/java/ Riga, 8th­9th of May, 2017 15% discount to JUG members, use JUG_LV code • • • 88
  89. 89. Cheat Sheets 89
  90. 90. Thank you! 90

×