Аналіз доповіді Руслана Черемина з JPoint 2016

доброго дня Всім, з вами знову Роман Поборчий в блозі JUG.ru і сьогодні ми розбираємо доповідь Руслана cheremin Черемина про escape-аналіз і скаляризацию:


Слайди можна подивитися і скачати тут. Традиційний disclaimer: про Java тільки розбирається в статті доповідь, а не сама стаття.

Сюжет
Тут у мене більша частина вражень   позитивні, все, що, як мені здається, в доповіді обов'язково має бути, в ньому є. Запропоновані зміни носять в основному косметичний характер.

Постановка завдання
Не знаю, як вас, а мене Руслан цілком переконав, що корисно розібратися, як в Java працює escape-аналіз. Якщо писати код з урахуванням цього знання, буде менше об'єктів в купі, менше gc і взагалі світ буде краще. Відповідь на питання «навіщо» є.

Тим не менш, жартівлива картинка, яка з'являється на 03:37, злегка затьмарює статистику. Після першого перегляду я запам'ятав тільки цей графік і як раз хотів поскаржитися, що немає жодних цифр про те, скільки можна заробити в середньому випадку». При другому перегляді виявилося, що цифри (~15% аллокаций, які можна усунути) згадуються. Якщо б вдалося знайти і показати схожий «нормальний» випадок, це б краще відклалося в пам'яті. Звичайно, такі дані зі своєї практики знайти на замовлення не завжди просто, немає так немає.

Висновки
Висновки і рекомендації у доповіді природно випливають з логіки розповіді, практично корисні і конкретні. Ми не просто розуміємо, що треба робити «добре» (наприклад, писати маленькі методи) і чому саме це треба робити. Ми ще і з'ясували, що у цього «добре» майже завжди можна дізнатися точну кількісну міру і навіть можна при необхідності її змінити! Чого ще бажати для щастя?

Хіба що можна було б глядачів застерегти: що-небудь обов'язково зламається, якщо ми станемо часто і бездумно перекрити дефолти компілятора, але це зажадає прикладів і часу і розмиє фокус.

Упущення
Чого мені тут не вистачає, так це опису методики експериментів: у перший раз результати запусків з'являються на слайді 16 (13:38), і там відразу фігурують 12 run'ів, обмежених не кількістю викликів, а часом. Чому саме так? У цьому є якийсь сенс, або так історично склалося? Чому в одних випадках час 5 секунд (слайди 16, 17, 19 і кілька інших), в інших 3 (слайди 68, 73 і кілька інших), а ще в інших і зовсім не вказано (слайди 89, 90, 91)?

Я впевнений, що тут методику достатньо пояснити один раз, просто щоб прибрати можливе недовіру, і у всіх подальших згадках стануть не потрібні повторювані деталі, докладніше про це в секції про слайди.

На сцені висить рушниця
Повісив рушницю не сам доповідач, удружив хтось із глядачів окриком з місця, але, так чи інакше, мова двічі зайшла про Φ-функції (зокрема, півхвилини починаючи з 16:40). Компілятор — одна з тих речей, для розуміння яких потрібні фундаментальні знання, але у нашої аудиторії ці знання є не завжди. Раз вже стався контакт двох-трьох розуміють, то варто спробувати в загальних рисах донести до всіх, про що ж мова, щоб вони не відчували себе обділеними.

Я задумався, чи не можна було на пальцях, раз заздалегідь підготовлених слайдів немає, за хвилину розповісти, що це за Φ-функції такі і яке приблизно відношення вони мають до теми розповіді. Орієнтуюся на себе, тобто на рівень людини, двадцять років тому здав спецкурс з компиляторам і з тих пір працював з ними тільки як користувач. У момент перегляду доповіді я, звичайно, не пам'ятав, що це. Отже, дивимося на слайд 23 і намагаємося пояснити, що там відбувається:



Ось що у мене вийшло:Внутрішнє представлення коду, що застосовується в HotSpot JIT, відповідає вимогам static single assignment, SSA-form. Це означає, що в кожну змінну присвоювання робиться тільки одного разу, а якщо ми кудись пишемо багато разів, то компілятор у себе заводить нову версію цієї змінної під кожну запис. Це потрібно для дуже великого числа оптимізацій, які він проводить якраз над своїм внутрішнім поданням. Тобто в нашому коді v з if-гілки, v з else-гілки і v з return-statement'а з точки зору компілятора   три різних змінних. Для випадків, подібних return-statement'у, якраз і потрібні Φ-функції. Це така абстракція, яка присвоює змінній значення в залежності від того, по якій гілці виконання ми в дану точку прийшли. Красу і сенс цієї функції в тому, що вона використовується без переривання базового блоку, хоча з точки зору людської логіки і містить всередині умовний оператор. Але функція, як і умовний оператор, несправжні (власне Φ   скорочення від слова «phony», фальшивий), такий дозволений чит. Тим не менш, ми досвідченим шляхом бачимо, що ця конструкція блокує escape-аналіз, реалізований в JIT'е.
Тільки текстом виходить все-таки досить важко, але якщо готуватися заздалегідь, то можна намалювати схему і не боятися говорити про SSA-form: на рівні концепції це нескладно. У реалізаціях напевно багато неочевидних деталей, і в деяких аудиторіях доведеться робити ще відступу, щоб пояснити, хто такі внутрішнє представлення і базовий блок, але тим не менш.

Якщо цей пост прочитає цей компиляторщик, він, можливо, навіть не знімаючи з полиці свій зачитаний до дірок Dragonbook, вкаже на помилки і заодно пояснить, як правильно розповідати.

Слайди
Стежити за ходом розповіді легко, слайди в цьому допомагають. Якщо десь є багато тексту або велика видача консольної утиліти, цікаві місця підсвічені. Прикладів з кодом досить багато, і вони по ходу розповіді змінюють один одного все швидше, від цього трохи втомлюєшся, але нічого критичного. До парі речей все ж хочеться привернути увагу.

Лазерна указка
Ті, хто читав попередній розбір, вже всі знають про використання лазерної указки. Виступ Руслана відбувається в такому ж широкому залі з двома екранами, як і у Сергія, і точно так само целеуказатель в кожен момент часу не видно приблизно третини аудиторії.

У кожному конкретному випадку слайд можна модифікувати, щоб було одразу зрозуміло, про що йде мова. Наприклад, слайд 13 (з'являється на 10:20) вилікувати зовсім просто:



Тут досить показувати не весь текст відразу, а послідовно відкривати рядки по мірі того, як до них доходить мова.

Повторювані елементи
При перегляді виступу мені весь час хотілося що-небудь зробити з кількісними результатами експериментів, які в одному і тому ж форматі зустрічаються на багатьох слайдах:



Що з ними не так?

  • Це багато щільного тексту, читати його, якби захотілося так робити, важко.
  • Цікавий момент настає не між run'ами, а десь всередині одного, зазвичай близько до початку першого. Тому результати, згруповані за run'ам (типу 0.01 байта на ітерацію) виглядають незвично, хоч їх і простіше отримати.
  • Моментальну інформацію про результат експерименту глядач отримує з кольору. Це нормально, але може створити труднощі для людей з червоно-зеленим розладом кольоросприйняття (а воно, як на зло, найпоширеніше).
Як це спростити?

Показовіша всього був би графік, де по осі X відкладено номер виклику (наскрізний для всіх run'ів), а по осі Y   кількість байт, аллоцированных в купі на цей виклик. У найгіршому випадку графік горизонталей, в хорошому   горизонталей перші скільки-то (тисяч) викликів, а потім падає в нуль. Заодно з нього було б видно, наскільки швидко включається оптимізація, як-то так:



У такому вигляді цікаво було б простежити за динамікою відбувається з ймовірнісної функцією (слайди 98-91). Там графік, швидше за все, повинен бути якийсь цікавий:



Можливо, я чогось не розумію, і дані для такого графіка, навіть з натяжками, в принципі отримати не можна. Тоді можна спробувати сильно зменшити розмір run'ів і будувати графік за ним.

Регулярні розбори
Якщо ви хочете отримати зворотний зв'язок щодо свого виступу, то я з радістю вам її дарую.

Що для цього потрібно?
  • Посилання на відеозапис виступу.
  • Посилання на слайди.

  • Заявка від автора. Без згоди самого доповідача нічого розбирати не будемо.
Все це потрібно відправити хабраюзеру p0b0rchy, тобто мені. Обіцяю, що відгук буде конструктивним і ввічливим, а також висвітлить і позитивні моменти, а не тільки те, що треба покращувати.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.