openjdk.ruOpenJDK на русском

JEP 271: Unified GC Logging

Единое журналирование GC

АвторJon Masamitsu
ОтветственныйBengt Rutisson
ТипFeature
ОбластьJDK
СтатусClosed / Delivered
Выпуск9
Компонентhotspot / gc
Обсуждениеhotspot dash gc dash dev at openjdk dot java dot net
ТрудоёмкостьL
ДлительностьL
Связан сJEP 158: Unified JVM Logging
РецензентыMikael Vidstedt
ОдобренMikael Vidstedt
Создан2014/10/06 21:19
Обновлён2017/06/02 19:18
Задача8059805

Аннотация

Заново реализовать журналирование GC на основе единой системы журналирования JVM, появившейся в JEP 158.

Что не является целью

Не ставится цель обеспечить, чтобы существующие анализаторы журналов GC работали с новыми журналами GC без изменений.

Не все записи журнала обязательно будут воспроизведены в новом формате журналирования.

Описание

Заново реализовать журналирование GC так, чтобы оно в разумных пределах соответствовало текущему формату журналов GC. Некоторые различия между новым и старым форматами неизбежно будут.

Тег «gc»

Идея в том, что -Xlog:gc (журналирование только с тегом «gc» на уровне info) должно быть похоже на то, что делал -XX:+PrintGC, а именно выводил одну строку на каждую сборку мусора. Поэтому log_info(gc)("message") нужно использовать очень осторожно. Не журналируйте на уровне info с одним только тегом «gc», если это не то единственное сообщение, которое должно выводиться на каждую сборку мусора.

Журналировать на уровне info с тегом «gc» допустимо, если он сочетается с другими тегами. Например:

log_info(gc, heap, ergo)("Heap expanded");

Идея здесь в том, что -Xlog:gc должно быть отчасти похоже на то, что вы раньше получали с -XX:+PrintGCDetails. Но это соответствие не такое строгое, как соответствие между -Xlog:gc и -XX:+PrintGC. Правило для -XX:+PrintGC было вполне ясным: одна строка на каждую сборку мусора. Правило для -XX:+PrintGCDetails никогда не было особенно ясным. Поэтому часть журналирования -XX:+PrintGCDetials может быть сопоставлена нескольким тегам, а часть — просто уровню debug для тега «gc».

Всё журналирование, связанное с GC, должно использовать тег «gc». Большая часть журналирования должна использовать не только тег «gc», а сочетать его с другими тегами по мере необходимости.

Есть и пограничные случаи, когда неясно, подходит ли тег «gc», например в коде выделения памяти. В большинстве таких случаев тег «gc», вероятно, использовать не следует.

Другие теги

Помимо «gc», есть много других тегов. Некоторые из них довольно чётко соответствуют старым флагам. Например, PrintAdaptiveSizePolicy более или менее соответствует тегу «ergo» (в сочетании с тегом «gc» и, возможно, другими тегами).

Verbose

Большая часть журналирования, которое было защищено флагом Verbose (флагом разработки), должна быть сопоставлена уровню trace. Исключение составляет журналирование, очень затратное с точки зрения производительности: в этом случае оно сопоставляется уровню develop.

Префикс

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

Динамическая настройка

Для некоторого журналирования требуется, чтобы данные были собраны на более раннем этапе. Единая система журналирования позволяет динамически включать и выключать любое журналирование с помощью jcmd. Это значит, что для журналирования, которое опирается на ранее собранные данные, недостаточно проверить, включено ли журналирование: нужны также проверки того, что данные доступны.