Згідно з пропозицією спільноти Java, зміни у збирачі сміття G1 Java зменшать накладні витрати на пам’ять та обробку, а також прискорять виконання JIT-компілятора Java C2, сприяючи хмарному розгортанню Java. Про це повідомляє InfoWorld.
Пропозиція OpenJDK спростить реалізацію бар’єрів G1, які записують інформацію про доступи до пам’яті застосунків, перемістивши їхні розширення із раннього етапу конвеєра компіляції C2 JIT на пізніший, йдеться у пропозиції.
Основою цієї пропозиції є зростання популярності хмарних розгортань Java, що призвело до більшої уваги до зменшення загальних накладних витрат JVM. Цілі плану включають скорочення часу виконання C2 під час використання колектора G1, створення бар’єрів G1 зрозумілими для розробників HotSpot, які не мають глибокого розуміння C2, і гарантування того, що C2 зберігає інваріанти відносного порядку доступу до пам’яті, точок безпеки та бар’єри. Іншою метою є збереження якості коду, згенерованого C2, з точки зору швидкості та розміру.
Метою пропозиції не є збереження поточного раннього розширення бар’єрів G1 як застарілого режиму, йдеться у пропозиції, додаючи, що перехід на пізнє розширення бар’єрів має бути повністю прозорим, тому застарілий режим непотрібний. Пропозицію було створено в середині грудня 2023 року та оновлено 9 квітня 2024 року.
Пояснюючи мотивацію плану, пропозиція посилається на зростаючу популярність хмарних розгортань і значні накладні витрати, пов’язані з оптимізацією компіляторів JIT, таких як C2. Попередні експерименти показують, що раннє розширення бар’єрів G1 збільшує накладні витрати C2 приблизно на 10–20% залежно від застосування. Зменшення цих накладних витрат є ключовим для того, щоб зробити платформу Java кращою для хмари, йдеться у пропозиції.
Ще один значний внесок у накладні витрати JVM – збирач сміття (GC). Відокремлення бар’єрного обладнання G1 від внутрішніх пристроїв C2 дасть змогу розробникам GC додатково оптимізувати та зменшити накладні витрати G1 за допомогою як алгоритмічних удосконалень, так і низькорівневої мікрооптимізації.
Нарешті, у пропозиції зазначено, що можливості C2 для оптимізації самого бар’єрного коду обмежені та що код подібної якості може бути згенерований, якби деталі реалізації бар’єру були приховані від C2 і розширені лише в кінці конвеєра компіляції. Тому автори пропонують розширити бар’єри G1 якомога пізніше в конвеєрі компіляції C2.
Раніше ProIT повідомляв, що Oracle прагне прискорити інновації у застосунках на основі Java.
Також ми розповідали про нові функції у Java 22.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
