Comments 28
На самом деле время, проводимое в состоянии stop-the-world можно существенно сократить. Например, поиск неиспользуемых объектов вполне можно проводить в fork'нутом процессе, который получил copy-on-write версию всех страниц родительского. Таким образом, пока он ищет, что бы такое удалить, ничего не стопорится. Нашёл — семафорит и передаёт через stdout конкретный список действий.
Почему такой подход до сих пор не используется в не-windows средах мне не особо ясно.
Почему такой подход до сих пор не используется в не-windows средах мне не особо ясно.
Непонятно, что такого может сторонний процесс, что не может поток внутри того же процесса. Дополнительные затраты на IPC?
Учитывая, что ищутся как раз-таки живые объекты, а не мертвые, то непонятно, как гарантировать нахождение всех живых обхектов, если не останавливать мутаторов. См. remark phase в CMS, например.
Учитывая, что ищутся как раз-таки живые объекты, а не мертвые, то непонятно, как гарантировать нахождение всех живых обхектов, если не останавливать мутаторов. См. remark phase в CMS, например.
перед форком нужно довести все треды до memory barrier. Это и есть stop-the-world
,
Было бы интересно почитать статью про сравнение сборщиков мусора Java с:
— .NET (какой там используется метод и как дела с остановкой мира?),
— PHP 5.3+ (там сборщик комбинированный, основанный и на счетчике ссылок в реальном времени, и на периодической чистке того, где счетчик ссылок спасовал).
— .NET (какой там используется метод и как дела с остановкой мира?),
— PHP 5.3+ (там сборщик комбинированный, основанный и на счетчике ссылок в реальном времени, и на периодической чистке того, где счетчик ссылок спасовал).
Остается вопрос почему не внедрят что-нибудь похожее в HotSpot?
Может Azul запатентовали алгоритм? Я бы не удивился.
Может Azul запатентовали алгоритм?
Реализовать тогда в виде какой-нибудь пристройки к OpenJDK и юзать в свободных от софтверных патентов странах как мы сейчас делаем со свободными реализациями проприетарных кодеков типа Lame и x264, не?
Да, алгоритм Azul C4 запатентован. При большом желании можно найти патент в Интернете.
главный вопрос: сколько такая чудо виртуальная машина стоит?
ну и чудожелезяка тоже
По стоимости не знаю, цены выставляю не я. :)
Говорят, в районе $5-6к: dhartford.blogspot.com/2011/06/hypervisor-vm-and-jvm-java-and-sla-and.html
Спасибо за статью. Есть тут у нас один монстр-проект, который очень аппетитно кушает память. Переписать его, скорее всего, денег не хватит, а вот железяку купить могут.
Неплохая статья, большое спасибо автору. Особо интересно узнать, что у нас есть люди использовавшие Azul в боевых инсталляциях.
Что хотелось бы добавить, так это чуть больше системности в изложении. В идеале, когда обзорная часть читается как учебник — тогда читатели любой степени подготовки смогут начать с нужного им места.
Я имею в виду что-то вроде — есть алгоритмы автоматической сборки мусора (copying, M-S, M-C, M-S-C) и есть коллекторы как высокоуровневая установка, применяющая один или несколько алгоритмов к разным областям памяти.
Выбор коллектора определяет
1) разбиение памяти на различные области
2) выбор одного из алгоритмов для каждой области
3) режим работы для каждой области — serial, parallel, mostly concurrent, concurrent
4) алгоритм аллокации памяти под новые объекты (в старом поколении) — линейная аллокация или free lists
Каждый алгоритм состоит из 1 или нескольких фаз (initial mark, mark, sweet, compact и тд и тп), которые могут хорошо или плохо параллелиться (выполняться многими тредами), быть или не быть concurrent (выполняться одновременно с тредами приложения). И вот тут как раз можно сказать про глобальный затык с фазой Compact у всех коллекторов и продолжить про Азул, которые изобрели C4 который единственный умеет делать concurrent compact.
Просто когда все эти вещи разложены по полочкам, становится проще ориентироваться в теме. Я не уверен, что человек без подготовки в GC сможет после прочтения статьи сказать, почему все коллекторы из таблицы используют копирующий сборщик для «Young Generation» или можно ли запустить CMS так, чтобы он не делал STW пауз.
Что хотелось бы добавить, так это чуть больше системности в изложении. В идеале, когда обзорная часть читается как учебник — тогда читатели любой степени подготовки смогут начать с нужного им места.
Я имею в виду что-то вроде — есть алгоритмы автоматической сборки мусора (copying, M-S, M-C, M-S-C) и есть коллекторы как высокоуровневая установка, применяющая один или несколько алгоритмов к разным областям памяти.
Выбор коллектора определяет
1) разбиение памяти на различные области
2) выбор одного из алгоритмов для каждой области
3) режим работы для каждой области — serial, parallel, mostly concurrent, concurrent
4) алгоритм аллокации памяти под новые объекты (в старом поколении) — линейная аллокация или free lists
Каждый алгоритм состоит из 1 или нескольких фаз (initial mark, mark, sweet, compact и тд и тп), которые могут хорошо или плохо параллелиться (выполняться многими тредами), быть или не быть concurrent (выполняться одновременно с тредами приложения). И вот тут как раз можно сказать про глобальный затык с фазой Compact у всех коллекторов и продолжить про Азул, которые изобрели C4 который единственный умеет делать concurrent compact.
Просто когда все эти вещи разложены по полочкам, становится проще ориентироваться в теме. Я не уверен, что человек без подготовки в GC сможет после прочтения статьи сказать, почему все коллекторы из таблицы используют копирующий сборщик для «Young Generation» или можно ли запустить CMS так, чтобы он не делал STW пауз.
Хорошо в стиле учебника об этом можно почитать здесь: blog.ragozin.info/2011/06/understanding-gc-pauses-in-jvm-hotspots.html
Я понимаю, что вы, наверное это знаете, просто для истории здесь оставлю ;)
Я понимаю, что вы, наверное это знаете, просто для истории здесь оставлю ;)
Вообще конечно бит NMT — весьма грязный хак, а постоянно падать с исключением процессора некошерно в плане производительности (хотя и позволяет убить stop-the-world фазу, тут компромисс). Но идея хороша.
И в порядке пиара — в этот четверг вечером в Москве пройдет митап на тему Java GC. Рассказывать будет Алексей Рагозин — мой бывший коллега, большой специалист в области GC и автор одного из GC-патчей для Open JDK.
Ссылка на мероприятие aragozin.timepad.ru/event/29364
Мероприятие не особо формальное, приглашаю приходить всех интересующихся, а автора — прийти и поделиться своим опытом с Azul. Я думаю, это всем будет интересно.
Ссылка на мероприятие aragozin.timepad.ru/event/29364
Мероприятие не особо формальное, приглашаю приходить всех интересующихся, а автора — прийти и поделиться своим опытом с Azul. Я думаю, это всем будет интересно.
Прочитал — возник резонный вопрос: а как на этом Azul C4 cебя поведут свеженькие Scala и Akka. Логичный ответ — надо попробовать. Но на сайте для триала предлагается «Zing JVM». Это оно или таки нет?
Почему на первых двух графиках нет G1? Баги багами, но начиная с JRE 7u4 Oracle считает G1 fully supported, то есть более не experimental — www.oracle.com/technetwork/java/javase/7u4-relnotes-1575007.html
И со вторым графиком не совсем понятно — на 2 гигабайтах у C4 паузы в несколько секунд, а на 5 гигах — уже сотые доли секунды. Правда ли это особенность C4? Какова вообще методика теста? Может, исходники есть?
И со вторым графиком не совсем понятно — на 2 гигабайтах у C4 паузы в несколько секунд, а на 5 гигах — уже сотые доли секунды. Правда ли это особенность C4? Какова вообще методика теста? Может, исходники есть?
На первых двух графиках нет G1, потому что тесты проводились в 2011 году, а официальная поддержка G1 началась с выпуска в мае 2012 года Java SE 7 Update 4.
Со вторым графиком — да, это особенность Azul C4, на heap-e большего размера достигается бОльшая эффективность. Там же рассказывается про методику теста. Подробности по ссылке:
Подробности про Azul C4
Со вторым графиком — да, это особенность Azul C4, на heap-e большего размера достигается бОльшая эффективность. Там же рассказывается про методику теста. Подробности по ссылке:
Подробности про Azul C4
Последний график-пример выглядит как-то странно. Паузы в случае с CMS растут и растут. Это была реальная, рабочая система, с реальными рабочими же настройками? Кажется, что в таком режиме реальная система просто не может быть применима. И тогда возникает вопрос, как же система в таком состоянии оказалась, что ее пришлось «спасать» переходом на Azul GC.
Если честно, возникает ощущение какого-то специально подогнанного примера.
А вообще Azul VM очень любопытный проект. Сам факт их существования неплохо подхлестывает прогресс в оптимизации JVM, и за это им мой большой респект
Если честно, возникает ощущение какого-то специально подогнанного примера.
А вообще Azul VM очень любопытный проект. Сам факт их существования неплохо подхлестывает прогресс в оптимизации JVM, и за это им мой большой респект
Oracle HotSpot CMS
IBM J9 optthruput делает практически то же самое.
optthruput работает все-таки не как CMS, а как ParallelOldGC
optthruput
The «optimize for throughput» (optthruput) policy disables the concurrent mark phase. The application stops during global garbage collection, so long pauses can occur. This configuration is typically used for large-heap applications when high application throughput, rather than short garbage collection pauses, is the main performance goal.
https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/diag/appendixes/cmdline/xgcpolicy.html
Sign up to leave a comment.
GC и большой heap: друзья или враги?