Комментарии 3
Или в этом нет большого смысла, потому что следом начнут автоматически расти очереди и задержки в работе приложения, и все как-нибудь само получится?
Нет, на уровне приложения узнать о работе Pacing'а не получится.
Технически он представляет собой маленькую паузу (по умолчанию не больше 10 мсек), которая вставляется в метод запроса TLAB'а из кучи. Такие паузы то появляются, то исчезают, динамически меняют длительность. О них сборщик никого не уведомляет, только в gclog потом выводит общую статистику об их использовании.
Думаю, реализовывать back pressure лучше опираясь на какие-нибудь другие, более устойчивые к настройкам JVM, сигналы и метрики, не полагаясь на внутреннее устройство сборщика, чтобы ничего не поломалось при переключении на другой сборщик.
Крутая статья! Пара небольших замечаний относительно Concurrent Evacuation фазы, т.к. барьер, помогающий при эвакуации(Load Reference Barrier), вроде как работает немного иначе:
Он срабатывает при каждой попытке загрузить ссылку, независимо для чтения или для записи в объект.
Даже если поток хочет только читать данные объекта, если forwarding pointer установлен, но объект еще не эвакуирован, будет осуществлена попытка атомарно установить копию самим барьером
Если барьер успешно устанавливает копию в forwarding pointer, текущая ссылка на объект после этого также будет обновлена, не дожидаясь фазы Update Reference, причем тоже атомарно
Дюк, вынеси мусор! — 6. Shenandoah GC