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. Это значит, что для журналирования, которое опирается на ранее собранные данные, недостаточно проверить, включено ли журналирование: нужны также проверки того, что данные доступны.