JVM: краткий курс общей анатомии

Слайды нашего доклада с Java-конференции Joker University Day 2015.

Если мы говорим про Java, то мы говорим про JVM, виртуальную Java машину, и про Java байткод, который исполняется на этой машине.

Внутреннее устройство JVM — непростое, но если вы решили связать свою профессиональную карьеру с Java, то очень важно понимать из каких частей состоит JVM, какая часть за что отвечает и как это все вместе работает хотя бы в самых общих чертах: это вам поможет в понимании того, как работает ваша программа.

В этом докладе мы не будем лезть в кишки какой-то конкретной реализации JVM, как это любят делать на основном потоке Joker, однако я покажу где кишки у JVM находятся, а также где находятся и для чего служат печень, сердце, почки, мозг и другие органы.

Владимир Парфиненко & Никита Липский

Transcript

1. JVM:  краткий  курс   общей  анатомии Никита  Липский Владимир  Парфиненко Excelsior  LLC
4. Никита  Липский • Более  20  лет  профессиональной  карьеры • Инициатор  проекта  Excelsior  JET   – работал  над  проектом  более  16  лет – как  идейный  вдохновитель – как  компиляторный  инженер – как  руководитель – и  много  в  каких  еще  ролях       • Open  source  проекты  WebFX и  Java ReStart – в  свободное  от  работы  время • twitter:  @pjBooms 4
5. Владимир  Парфиненко • Менее  20  лет  профессиональной  карьеры • Один  из  разработчиков  Excelsior  JET   – Программирую  компиляторы • Активно  учу  студентов  в НГУ • twitter:  @cypok 5
6. План  доклада • Java  class  file  and  bytecode • Classloading engine • Execution  engine:  interpretators,  JIT,  AOT • Meta information  access  subsystem:  reflection,  indy,  JNI • Threading,  exception  handling,  synchronization • Memory  management:  heap,  allocation,  GC • Manageability  and  Monitoring 6
7. Java  class  file  &  bytecode 7
8. Java class  file   • 1  класс  <–> 1  класс-­‐файл • Constant  Pool   – числа,  строки – указатели  на  классы,  методы,  поля • Описание  класса 8 – имя – модификаторы – супер  класс – супер  интерфейсы – поля – методы – атрибуты
9. Java class  file • Поля,  методы  тоже  имеют  атрибуты  (например,  значения   константных  полей) • Главный  атрибут  метода  – это  его  код: Java байт-­‐код 9
10. Java  bytecode • Массив  инструкций • Стэк операндов  инструкций  метода • Массив  локальных  переменных  (аргументы  метода,   локальные  переменные) 10
11. Java  bytecode Инструкция  берет  свои  операнды  со  стэка и    кладет результат  на  стэк. Пример: 11 0: iload 3 // загрузить на стэк переменную #3 2: bipush 5 // загрузить на стэк константу 5 4: iadd // сложить два операнда со стэка и загрузить // на стэк результат 5: istore 4 // снять значение со стэка в переменную #4
12. JVM:  предисловие 12
13. Программа  для  JVM Любая  программа  исполняемая  на  JVM  имеет? 13
14. Программа  для  JVM Любая  программа  исполняемая  на  JVM  имеет: • main  класс public static void main(String[] args) • сlasspath – список  директорий  и  архивов  (jar  файлов) • В  мире  веб  приложений  программа  для  JVM  – это  веб  сервер – Tomcat,  GlassFish и  т.п. 14
15. Java  Runtime Для  исполнения  программы  на  JVM  одной  JVM  не  достаточно.   Нужен  Java  Runtime Environment: • JVM • Платформенные  классы – core  классы  (j.l.Object,  j.l.String и  т.д.) – Java  standard  APIs  (IO,  NET,  NIO,  AWT/Swing и  т.д)         • Реализация  нативных методов  платформенных  классов  (OS   specific) • Вспомогательные  файлы  (описатели  временных  зон,  медиа   ресурсы  и  т.п.) 15
16. Анатомия  JVM 16 OS  +  CPU Monitoring AOT Bytecode Classloading engine Bytecode Verification Execution  engine: interpreter,  JIT Threading Synchronization Meta information Memory  management, Garbage  Collection Native  methods
17. Classloading engine 17 OS  +  CPU Monitoring AOT Bytecode Classloading engine Bytecode Verification Execution  engine: interpreter,  JIT Threading Synchronization Meta information Memory  management, Garbage  Collection Native  methods
18. Загрузка  классов • Где  JVM берет  классы для  исполнения: – Из  Java  Runtime  (платформенные  классы) – Из  classpath приложения   – Авто-­‐сгенеренныена  лету  (Proxy,  Reflection accessors,  реализация   invoke  dynamic) – Предоставленные  самим  приложением 18
19. Загрузка  классов • Каждый  класс  грузится  каким-­‐то  загрузчиком  классов: – Платформенные  классы  грузятся  bootstrap загрузчиком – Классы  из  classpath приложения  – системным  загрузчиком   (AppClassLoader)   – Классы  приложения  могут  создавать  свои  загрузчики,  которые   будут  грузить  классы 19
20. Загрузка  классов • Каждый  класс  грузится  каким-­‐то  загрузчиком  классов: – Платформенные  классы  грузятся  bootstrap загрузчиком – Классы  из  classpath приложения  – системным  загрузчиком   (AppClassLoader)   – Классы  приложения  могут  создавать  свои  загрузчики,  которые   будут  грузить  классы • Загрузчик  классов  образует  уникальное  пространство  имен   классов 20
21. Старт  JVM • Грузится  main  класс  системным  загрузчиком  (из  classpath приложения) – Провоцирует  загрузку  части  платформенных классов  (core) • Исполняется  метод  main(String[]  args) 21
22. Процесс  загрузки  класса   (создание  класса) • Читается  class  file   – Проверяется  корректность  формата  (может  выбросить   ClassFormatError) • Создается  ран-­‐тайм  представление  класса  в  выделенной   области  памяти   – runtime  constant  pool  in  Method  Area  aka  Meta  Space aka   Permanent  Generation • Грузятся  суперкласс,  суперинтерфейсы 22
23. Линковка • Верификация  байт-­‐кода • Подготовка • Разрешение  символьных  ссылок 23
24. C: StackOverflowError A: Программа  зациклится B:  VerifyError D: Другой  вариант Что  произойдет  при  исполнении  этого  байт-­‐кода?
25. Верификация  байт-­‐кода • Происходит  с  классом  один  раз • Проверка  корректности  инструкций  (корректности   переходов) • Проверка  выхода  за  пределы  стэка операндов  и  локальных   переменных • Проверка  совместимости  типов 25
26. Верификация  байт-­‐кода • Верификация  методом  вывода  типов (type  inference   verification) – Потоковый  анализ:  итеративное  уточнение  типовой  информации   до  достижения  неподвижной  точки • Раздельная  (split) верификация  (type  checking  verification) – Неподвижная  точка  для  потокового  анализа  кодируется  внутрь   байт-­‐кода  специальным  атрибутом.  Т.о.  верификация  происходит   за  один  проход     26
27. Разрешение  символьных  ссылок Класс  может  иметь  ссылки  на  другие  классы и  поля,  методы   других  классов • Ленивое  разрешение   – ссылки  разрешаются  при  первом  доступе • Энергичное  разрешение – разрешаются  все  ссылки  какие  возможно   27
28. Инициализация  класса • Вызов  статического  инициализатора  класса • Случается  при  first  use: – new – доступ  до  статического  поля – вызов  статического  метода • Провоцирует  инициализацию  супер-­‐класса  и  супер-­‐ интерфейсов  с  default  методами 28
29. Execution  engine 29 OS  +  CPU Monitoring Bytecode Classloading engine Execution  engine: interpreter,  JIT Threading Synchronization Meta information Memory  management, Garbage  Collection Native  methods Bytecode Verification AOT
30. Исполнение  Java  байт-­‐кода JVM  может  исполнять  байт-­‐код  двумя  способам: • Интерпретировать • Транслировать  в  машинный  код,  который  будет   исполняться  непосредственно  на  CPU 30
31. Интерпретатор pc = 0; do { fetch opcode at pc; if (operands) fetch operands; execute the opcode; calculate pc; } while (there is more to do); 31
32. Компиляторы • Неоптимизирующие – “что  вижу,  то  пою” • Простые оптимизирующие  (пример  HotSpot Client) – Простое  внутреннее  представление  (IR) – Простые  оптимизации – Pros:  быстрая  компиляция • Сложные  оптимизирующие  (пример  HotSpot Server) – Сложный  IR,  более  мощные  оптимизации – Pros:  более  оптимальный  код 32
33. • Динамические  (Just-­‐In-­‐Time  – JIT).   – Трансляция  в  машинный  код  происходит  во  время   исполнения  программы • Статические  (Ahead-­‐Of-­‐Time  – AOT) – Трансляция  происходит  до  исполнения  программы 33 Компиляторы
34. Динамические  компиляторы  (JIT) • Работают  одновременно  с  исполняемой  программой • Компилируют горячий код • Горячий  код  вычисляется  с  помощью  динамического   профилировщика • Используют  информацию  времени исполнения  для  оптимизаций 34
35. Статические компиляторы  (AOT) • Не  ограничены  в  ресурсах  для  оптимизации  программ • Компилируют  каждый  метод  программы  применяя  самые   агрессивные  оптимизации • На  оптимизацию  не  тратятся  ресурсы  во  время  исполнения   программы  (быстрее  старт) 35
36. Статические компиляторы  (AOT) Интересный  факт: Во  время  работы  статически  скомпилированной  Java программы может  не  исполниться  ни  одного  Java  байт-­‐ кода. Вопрос:  а  где  JVM? 36
37. Meta  information subsystem 37 OS  +  CPU Monitoring AOT Bytecode Classloading engine Bytecode Verification Execution  engine: interpreter,  JIT Threading Synchronization Meta information Memory  management, Garbage  Collection Native  methods
38. Reflection • Позволяет  доступаться до  классов,  полей,  методов  по   имени  из  Java  программы • Реализуется  в  JVM  через  доступ  в  Meta space   • Ключевая  возможность  Java  для  многих  популярных   фреймворков и  реализаций  языков  на  JVM   38
39. Method  Handles  and   invokedynamic (JSR-­‐292,  indy) • Indy:  программируемый  вызов – для  эффективной  реализации  динамических  языков  на  JVM • MethodHandle – целевой  объект  вызова  через   invokedynamic – может  быть  доступом  к  полю,  методу – комбинацией  других  MethodHandle – может  использоваться  отдельно  от  indy:  Reflection  2.0 39
40. Java  native  interface  (JNI) • Связывает  JVM  c  внешним  миром  (OS) • Си интерфейс  к  JVM – Не  зависит  от  реализации  JVM – Используется  для  реализации  native  методов на  языке    С  (или  другом   системном  языке) – С  помощью  JNI  написаны  платформенно-­‐зависимые  реализации   Java  SE  API:  IO,  NET,  AWT • Реализуется  в  JVM  как  доступ  к  Meta space 40
41. Threading  and  synchronization 41 OS  +  CPU Monitoring AOT Bytecode Classloading engine Bytecode Verification Execution  engine: interpreter,  JIT Threading Synchronization Meta information Memory  management, Garbage  Collection Native  methods
42. java.lang.Thread • Java  поток  мапируется на  нативный поток  в  соотношение  1-­‐1 • С  потоком  связана  память  используемая  для  локальных   переменных  и  стэка операндов  методов (фреймов  методов):   стэк (stack) – Размер  стэка – параметр  JVM:  -­‐Xss • Имеет  информацию  о  стэке вызовов  методов  потока  (stack   trace) – В  любой  момент  может  о  нем  рассказать 42
43. Обработка  исключений   Знание  о  стэке вызовов  помогает  в  обработке  исключений: 43 method  7 throw method  3 catch method  6 .  .  . method  2 .  .  . method  3 catch method  2 .  .  . PC PC exception  caught
44. Потоки  и  Java  Memory  Model 44 // Thread 1: Shared.data = getData(); Shared.ready = true; // Thread 2: while (!Shared.ready) { // wait } receivedData = Shared.data;
45. Потоки  и  Java  Memory  Model • Разделяемая  (shared)  память – Объекты  создаваемые  в  одних  потоках  могут  быть  далее   доступны  из  других • Семантика  доступа  к  разделяемой  памяти  из  разных   потоков  описывается  в  Java  Memory  Model  (Java  Language   Specification) – Семантика  нетривиальна  в  связи  с  тем,  что  порядок  выполнения   инструкций  в  методе  не  обязан  быть  линейным 45
46. Синхронизация • Для  безопасного  доступа  к  разделяемой  памяти  между   потоками • В  наивной  реализации  используются  средства  ОС – ОС монитор  есть  в  каждом  Java  объекте  как  скрытое  поле   • Оптимизирована  когда  конкуренция  за  ресурс  происходит   много  реже,  чем  вход  в  synchronized 46
47. Memory  management 47 OS  +  CPU Monitoring AOT Bytecode Classloading engine Bytecode Verification Execution  engine: interpreter,  JIT Threading Synchronization Meta information Memory  management, Garbage  Collection Native  methods
48. Выделение  памяти • Реализация  оператора  new • Объекты  выделенные  с  помощью  оператора  new   располагаются   в  т.н.  куче  (Java  heap) • Организация  Java  heap  JVM-­‐cпецифична • Разметка  (layout)  Java  объекта тоже  JVM  специфична. 48
49. Java  heap Внутренняя  топология  Java  кучи  сильно  зависит  от  алгоритма   GC.  В  разных  реализациях  может  делиться  на: • Область  молодого  и  старого  поколения • Разбиваться  на  блоки • Большие  объекты  могут  управляться  особым  образом 49
50. Аллокация объектов • Должна  быть  быстрой – JVM  запрашивает  у  OC  память  не  под  один  объект,  а  сразу  на   много   – Аллокация методом  продвижения  границы • Потоко-­‐безопасной  (thread-­‐safe),  но  при  этом   параллельной  (не  блокирующей) – Thread  local  heaps:  каждый  поток  “грызет” свой  кусок  памяти 50
51. Layout  Java  объекта Не  специфицируется  JVM,  но  по  факту  требует: • Java  Object  header – Указатель  на  класс – Монитор  (lock) – Identity  hashcode – Флаги  для  GC • Поля – Могут  быть  переупорядочены  из  соображений  экономии   размера,  выравнивания,  особенностей  целевой  архитектуры 51
52. Сборка  мусора 52
53. Сборка  мусора 53
54. Что  такое  мусор? 54
55. Что  такое  мусор? 55
56. Что  такое  мусор? 56
57. Что  такое  мусор? 57
58. Мусор Мусором  являются  объекты,  которые  не  могут   использоваться  программой Вопрос:  А  какие  объекты  могут использоваться? 58
59. Мусор Мусором  являются  объекты,  которые  не  могут   использоваться  программой Вопрос:  А  какие  объекты  могут использоваться? Ответ:   Не  мусор! 59
60. Не  мусор 1. Объекты  в  статических  полях  классов 2. В  локальных  переменных 3. … всё? 60
61. Не  мусор Object o = new Object(); ... 61
62. Не  мусор  2 1. Объекты  в  статических  полях  классов 2. В  локальных  переменных Доступных  из  фрейма  метода  (локальные  переменные  и   стэк операндов) Какого  метода? 62
63. Не  мусор 63
64. Не  мусор  2  возвращается   1. Объекты  в  статических  полях  классов 2. В  локальных  переменных Доступных  из  фрейма  метода фреймов  методов   (локальные  переменные  и  стэк операндов)  стэка вызовов   всех  Java  потоков. 3. Объекты,  на  которые  ссылается  “не  мусор” 64
65. Корневое  множество  объектов (GC  roots) 1. Объекты  в  статических  полях  классов 2. Объекты  доступные  со  стэка Java  потоков 3. Объекты  из  JNI  ссылок  в  native  методах 65
66. Не  мусор  3 Не  мусор  aka живые  объекты – это: 1. Объекты  из  корневого  множества   2. Объекты,  на  которые  ссылаются  живые  объекты Все  остальное  – мусор. 66
67. Трассирующие  сборщики • Mark-­‐and-­‐sweep – Помечает  живые  объекты  (mark),  “выметает”  (удаляет)  мусор   (sweep) • Stop-­‐and-­‐copy – Копирует  живые  объекты  в  специальное  место  (copy)   – Освободившиеся  место  (мусор  и  места  где  были  живые  объекты)   может  использоваться  для  новой  аллокации 67
68. Stop  the  World • Живые  объекты  определены  для  определенного  момента   исполнения программы – При  исполнении  множество  меняется • Чтобы  собрать  мусор  в  общем  случае  нужно  остановить   потоки,  чтобы  определить  где  мусор  (STW  пауза) 68
69. Stop  the  World Одна  из  основных  задач  современных  сборщиков  мусора  – это  уменьшение  времени  STW  паузы.  Методы  уменьшения: • Инкрементальный   – собирать  не  весь  мусор  в  паузе • Параллельный – собирать  мусор  во  многих  потоках  в  паузе • Одновременный  (concurrent) – собирать  мусор  одновременно  с  работой  программы  (не   останавливая  потоки)   69
70. Поколенная  сборка  мусора Гипотеза  о  поколениях:  большинство  объектов  умирает   молодыми Поколенный  (generational)  GC: • частный  вид  инкрементального • во  время  т.н.  малых  сборок  удаляем  мусор    среди  молодых   объектов • объекты,  пережившие  одну  или  несколько  сборок,   перемещаем  в  область  старого  поколения   70
71. GC:  advanced  topics • Финализаторы и  слабые  ссылки • GC  (safe)  points • Точные  vs.  консервативные  GC • Способы  борьбы  с  фрагментацией  кучи • Real  time  GC • Class  GC • Базовые  алгоритмы  GC • Конкретные  реализации: – В  одной HotSpot JVM  пять(!)  разных  GC 71
72. Manageability  &  Monitoring 72 OS  +  CPU Monitoring AOT Bytecode Classloading engine Bytecode Verification Execution  engine: interpreter,  JIT Threading Synchronization Meta information Memory  management, Garbage  Collection Native  methods
73. Manageability  &  Monitoring JVM  знает  про  вашу  программу  всё: • про  все  загруженные  классы • про  все  живые  объекты • про  все  потоки • про  все  исполняемые  методы  потоков Почему  бы  не  поделиться  с  вами  этой  информацией  во  время   исполнения?   73
74. Manageability  &  Monitoring JVM  Tool  Interface  (JVM  TI): • отладчики   • профилировщики Java  Management  Beans: • Инструменты  мониторинга  запущенных  приложений – JConsole,  JMX  console,  AMC   – Visual  VM – Java  Mission  Control 74
75. Абстрактная  JVM 75 OS  +  CPU Monitoring AOT Bytecode Classloading engine Bytecode Verification Execution  engine: interpreter,  JIT Threading Synchronization Meta information Memory  management, Garbage  Collection Native  methods
76. Реализации  JVM Совместимые  с Java  SE  спецификацией: • Oracle  HotSpot • Oracle  JRockit (RIP) • IBM  J9 • Excelsior  JET • Azul  (HotSpot based,  но  свой  GC) • SAP,  RedHat (свои  порты  HotSpot на  разные  платформы) 76
77. Заключение • JVM  сложная,  но  жутко  интересная  штука • Java  – золотая  середина  современных  IT  технологий: – Подробно  специфицирована – Эффективность  помноженная  на  гибкость:   • типизированностьJava  байт-­‐кода  позволяет  его  транслировать  в  машинный  код   очень  эффективно • при  этом  reflection,  indy, динамическая  загрузка  придает  платформе  высокую   гибкость  и  динамичность • Все  реализации  JVM  в  постоянном  развитии  на  острие  науки  и   технологий 77
78. Вопросы  и  ответы Никита  Липский, Excelsior nlipsky@excelsior-­usa.com twitter:  @pjBooms Владимир  Парфиненко, Excelsior vparfinenko@excelsior-­usa.com twitter:  @cypok 78