Garbage Collection

[Palych]

Но G1 тоже требует настройки и у него есть ахилесовы пяты: ...Weak, Soft and etc references...

IMHO это не слабости коллектора, а свидетельство неправильной концепции:
Сборщик мусора по определению должен удалять объекты, которые не нужны приложению.
А эти недоссылки позволяют приложению использовать объекты, которые пока еще не нужны сборщику мусора.
Их использование подразумевает что сборщик мусора включается только когда памяти становится мало.
А это не всегда эффективно, и неправильно.
Им нужно отдельный сборщик для Weak/Soft and etc references...

[kostik78]

Но G1 тоже требует настройки и у него есть ахилесовы пяты: ...Weak, Soft and etc references...

IMHO это не слабости коллектора, а свидетельство неправильной концепции:
Сборщик мусора по определению должен удалять объекты, которые не нужны приложению.
А эти недоссылки позволяют приложению использовать объекты, которые пока еще не нужны сборщику мусора.
Их использование подразумевает что сборщик мусора включается только когда памяти становится мало.
А это не всегда эффективно, и неправильно.
Им нужно отдельный сборщик для Weak/Soft and etc references...

Проблема сборки мусора выглядит простой только на первый взгляд. Так что имхо прежде чем сетовать изучите предмет детальнее или хотя бы печальный опыт создателей Golang которые тоже как "дартаяны" кричали что JVM GC говно и они шас забабахают супер пупер GC и застряли с этим. Только к версии 1.6 (после фиксанья багов в новой имплементации GC в версии 1.5) что-то получилось более или менее соотвествующее. При этом Golang концептуальнее создает меньше временного мусора чем JVM. То бишь задача для решения должна была быть проще.

[Flash-04]

Всё это теоретизирование, а на практике я работал с двумя enterprise level приложениями которые обрабатывают хренову кучу данных в real-time. То что написано на Java - глючное и прожорливое. То что написано на C++ быстрое и масштабируемое в отличие от. Стоит ли говорить что последнее за несколько лет отобрало большую часть рынка у первого (которое считалось лучшим минимум 5 лет).

[kostik78]

Всё это теоретизирование, а на практике я работал с двумя enterprise level приложениями которые обрабатывают хренову кучу данных в real-time. То что написано на Java - глючное и прожорливое. То что написано на C++ быстрое и масштабируемое в отличие от. Стоит ли говорить что последнее за несколько лет отобрало большую часть рынка у первого (которое считалось лучшим минимум 5 лет).

На жабе писать можно по разному также как и на С++ можно написать глючное, корявое и немаштабируемое. Так что дело имхо как говорят связисты: "дело было не в бобине, расп...яй сидел в кабине"

[Мальчик-Одуванчик]

Всё это теоретизирование, а на практике я работал с двумя enterprise level приложениями которые обрабатывают хренову кучу данных в real-time. То что написано на Java - глючное и прожорливое. То что написано на C++ быстрое и масштабируемое в отличие от. Стоит ли говорить что последнее за несколько лет отобрало большую часть рынка у первого (которое считалось лучшим минимум 5 лет).

Но в последнем случае наверняка придется писать собственный аллокатор, а это мало кто сможет соорудить грамотно.
Хотя семантика переноса, введенная в стандарт 11 года позволяет во многих вещах обходиться без активного использования динамической памяти.

[Flash-04]

Хе-хе, я вам говорю о реальном решении которое сейчас топчет конкурентов сапогами

[Мальчик-Одуванчик]

Интересно, а как сборщик мусора виртуальной машины джавы синхронизируется с остальными процессами в многоядерной системе?

[Palych]

G1 не работает по лимиту памяти как CMS или другие Java GC. Он как раз статистичесикий. Чем дольше Java работает тем стабильнее паузы, конечно если паттерн аллокации памяти не скачет туда сюда рандомно.

Кстати, а почему тогда у Сабины пила?
Сабина, признавайся - пила или не пила?

[Palych]

Хе-хе, я вам говорю о реальном решении которое сейчас топчет конкурентов сапогами

Какого рода приложение?

[kostik78]

Интересно, а как сборщик мусора виртуальной машины джавы синхронизируется с остальными процессами в многоядерной системе?

Что именно синхронизирует - в какой области Вас интересует? Java heap состоит из нескольких зон и сам GC имеет несколько различных фаз. Соотвественно разные виды синхронизации Если Вы про world stop phase - то там все просто - JVM все процессы притормаживает в native code пока GC выполняет финальную фазу. Остальные фазы обычно работают параллельно с основным приложенем. В этом memory metadata что нужна GC защищается обычными синхронизационными примитивами. В случае линуха это pthread lock.
Если что спрашивайте конкретнее - я свое время с CMS на мучалсяизучался вплодь до исходников JVM native. С G1 пока только одна более или менее серезьная проблема была - он не учитывает -noclassgc и по этой причине иногда JVM раком встает. Баг в Java 9 пофиксали а в 8 нужно убрать опцию. Хотя она и правда остатки прошлого. Не нужно имхо в G1 этой оптимизации.

[kostik78]

G1 не работает по лимиту памяти как CMS или другие Java GC. Он как раз статистичесикий. Чем дольше Java работает тем стабильнее паузы, конечно если паттерн аллокации памяти не скачет туда сюда рандомно.

Кстати, а почему тогда у Сабины пила?
Сабина, признавайся - пила или не пила?

Пила равномерна потому что аллокация памяти линейная (равномерная пила это как раз что нужно добиваться в серверном Java code) и G1 работает постоянно чтобы meet the target of execution time. Включите статистику и все увидите, что там пила та пила да не такая как в CMS, где основной сборщик мусора тригирился по memory threshold.

[Palych]

там пила та пила да не такая как в CMS, где основной сборщик мусора тригирился по memory threshold.

То есть - высота зубьев пилы не зависит от размера Xmx?

[kostik78]

там пила та пила да не такая как в CMS, где основной сборщик мусора тригирился по memory threshold.

То есть - высота зубьев пилы не зависит от размера Xmx?

Ответ на этот вопрос не совсем прост. Но в целом не зависит. Но в G1 есть ньюанс, он чем то похож на CMS если Вы расcматриваете отдельный регион (eden gen + metadata + old gen), но в отличие от CMS у которого был только один такой регион G1 делит хип на множество таких кубиков. Там на самом деле есть threshold -XX:InitiatingHeapOccupancyPercent=45. Он говорит G1 на начальном этапе как вести себя пока статистика не набрана еще. Например у нас в продакщен первые 24 часа можно увидеть несколько пауз которые привышают XX:MaxGCPauseMillis но по истечении 24 часов 92% пауз будут <=200ms. И раз в 72-80 часов у нас случаются 800ms паузы но из за FinalReferences что известная проблема у G1. Оптимизация по времени привела к тому что он не очень успевает вызывать finalize на SSL sockets. Ну это отдельная история - как я уже сказал - это детали имплементации

[Flash-04]

Какого рода приложение?

Splunk

[Сабина]

12Gb хип?? Жава 8 вроде 1гб максимум, не?