Требуется пояснение о Parallel Full GC для G1

Question

В составе java JDK10 JEP307 был Parallel Full GC для G1 , реализованный.

Я пытался понять его описание, но все еще не уверен, что понял идею правильно.

Я сомневаюсь, что это связано с Одновременным мусором

Answer 1

Java 10 сокращает время полной GC-паузы за счет итеративного улучшения существующего алгоритма. До Java 10 G1 Full GC работали в одном потоке. Это верно - ваш 32-ядерный сервер и его 128 ГБ будут останавливаться и приостанавливаться до тех пор, пока один поток не уберет мусор. В Java 10 это было улучшено для параллельной работы. Это означает, что полные GC будут работать в нескольких потоках параллельно, хотя все еще останавливают прогресс JVM, пока он не завершится. Число потоков может быть дополнительно настроено с помощью -XX:ParallelGCThreads.

Answer 2

G1 Collector
Еще одна прекрасная оптимизация, для которой только что вышло обновление Java 8, - дедупликация строки G1 Collector. Поскольку строки (и их внутренние массивы char []) занимают большую часть нашей кучи, была проведена новая оптимизация, которая позволяет сборщику G1 идентифицировать строки, которые дублируются более одного раза в вашей куче, и исправлять их, чтобы они указывали на один и тот же внутренний символ [], чтобы избежать неэффективного размещения нескольких копий одной и той же строки в куче. Вы можете использовать аргумент -XX:+UseStringDeduplicationJVM, чтобы проверить это.

Параллельный полный GC в G1GC
Сборщик мусора G1 был печально известен тем, что выполнял однопоточный полный цикл GC. В то время, когда вам нужно все оборудование, которое вы можете собрать для поиска неиспользуемых объектов, мы ограничиваемся одним потоком. В Java 10 они исправили это. Полный GC теперь работает со всеми ресурсами, которые мы к нему добавляем.

Параметры JVM: -Xlog:gc,gc+cpu::uptime -Xmx4g -Xms4g -Xlog:gc*:details.vgc Это выведет каждое событие GC и его использование ЦП на стандартный вывод, показывая только время работы в качестве тега. Настройка -Xlog:gc* аналогична -XX:+PrintGCDetails предыдущих версий Java.

Answer 3

Java 10 сокращает время полной GC-паузы за счет итеративного улучшения существующего алгоритма. До Java 10 G1 Full GC работали в одном потоке. Это верно - ваш 32-ядерный сервер и его 128 ГБ будут останавливаться и приостанавливаться до тех пор, пока один поток не уберет мусор. В Java 10 это было улучшено для параллельной работы. Это означает, что полные GC будут работать в нескольких потоках параллельно, хотя все еще останавливают прогресс JVM, пока он не завершится. Число потоков может быть дополнительно настроено с помощью -XX:ParallelGCThreads.

Это приятное улучшение алгоритма G1 в Java 10, которое должно сократить время пауз в худшем случае для большинства пользователей. Означает ли это, что паузы Java GC остались в прошлом? Нет - это уменьшает проблему, но поскольку G1 не запускает свои циклы сбора одновременно с вашим приложением, оно все равно будет периодически приостанавливать работу приложения, и паузы Full GC по-прежнему увеличиваются с увеличением размера кучи. В нашем последнем сообщении в блоге мы говорили о некоторых других сборщиках мусора, которые могут решить эту проблему в будущем.

Answer 4

Сборщик мусора G1 был печально известен выполнением однопоточного полного цикла GC. В то время, когда вам нужно все оборудование, которое вы можете собрать для поиска неиспользуемых объектов, мы ограничиваемся одним потоком. В Java 10 они исправили это. Полный GC теперь работает со всеми ресурсами, которые мы к нему добавляем. Чтобы продемонстрировать это, я написал ObjectChurner, который создает набор байтовых массивов разных размеров. Это держится на объектах в течение некоторого времени. Размеры рандомизированы, но в контролируемой, повторяемой форме.

Answer 5

Наконец-то я понял про Parallel Full GC для G1

Сделано по умолчанию в JDK 9 и введено в JDK 7

Эффективно и одновременно работать с кучами не удается при полной сборке мусора в некоторых случаях полная сборка мусора неизбежна. Она эффективно и одновременно работает с очень большими кучами. Обычный сборщик мусора разделил бы кучу на молодых (эден и выживший) и Старое поколение (логическое разделение) G1 разбивает кучу на множество небольших регионов. Такое разделение позволяет G1 выбрать небольшую область для быстрого сбора и обработки.

В JDK9 используется один поток для полного GC

В JDK 10 используется многопоточная (параллельная) сборка мусора '

Answer 6

В качестве упрощенного объяснения - сборщики мусора имеют два возможных типа сбора: «инкрементный» и «полный». Инкрементный сбор лучше всего подходит для того, чтобы держаться подальше, так как он будет часто выполнять небольшую работу. Полная сборка часто более разрушительна, так как она занимает больше времени и часто требует остановки всего выполнения программы во время ее работы.

Из-за этого большинство современных GC (включая G1), как правило, стараются обеспечить, чтобы при нормальных обстоятельствах инкрементного сбора было достаточно, и полного сбора никогда не потребуется. Однако, если множество объектов разных поколений получают право на сборку мусора непредсказуемым образом, то иногда полный сборщик мусора может быть неизбежным.

В настоящее время полная реализация коллекции G1 является однопоточной. И вот тут-то и появляется этот JEP - он стремится распараллелить его, так что когда полный GC действительно происходит, он быстрее в системах, которые могут поддерживать параллельное выполнение.