Garbage Collection

[Palych]

А почему а Java сборка мусора начинается когда его накопилось достаточно много (70%)?
Почему не убираться когда для этого есть ресурсы (CPU time)?
Как с этим в других системах?

[iDesperado]

А почему а Java сборка мусора начинается когда его накопилось достаточно много (70%)?
Почему не убираться когда для этого есть ресурсы (CPU time)?
Как с этим в других системах?

который из них ? у java их несколько ...

[Palych]

который из них ? у java их несколько ...

Когда я смотрел туда (лет 5 назад) - был только один экспериментальный коллектор, который вроде бы по-другому работал.
Назывался он как-то отталкивающе... Agressive?

[valchkou]

который из них ? у java их несколько ...

Когда я смотрел туда (лет 5 назад)

палыч, ну ты и юморист, 5 лет назад посмотрел и все думал думал и наконец то решил задать вопрос.

[Palych]

А думал за 5 лет вырастит целое поколение специалистов, способных без труда ответить на этот вопрос...
Впрочем never mind. Погуглю как-нибудь...

[kyk]

А почему а Java сборка мусора начинается когда его накопилось достаточно много (70%)?

Как с этим в других системах?

У меня по понедельникам

[perasperaadastra]

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

Спасибо что напомнили.

[Сабина]

А думал за 5 лет вырастит целое поколение специалистов, способных без труда ответить на этот вопрос...
Впрочем never mind. Погуглю как-нибудь...

Ну вы даете. Вас же попросили тип коллектора уточнить
Для high throughput систем хорошо работает G1GC, но у него конечно свое понимание как оптимизировать процесс, а не просто "кога у меня для тебя есть CPU - тогда и включайся

G1 GC is an incremental parallel compacting GC that provides more predictable pause times compared to CMS GC and Parallel Old GC. By introducing a parallel, concurrent and multi-phased marking cycle, G1 GC can work with much larger heaps while providing reasonable worst-case pause times. The basic idea with G1 GC is to set your heap ranges (using -Xms for min heap size and -Xmx for the max size) and a realistic (soft real time) pause time goal (using -XX:MaxGCPauseMillis) and then let the GC do its job.

With the introduction of G1 GC, HotSpot moves away from its conventional GC layout where a contiguous Java heap splits into (contiguous) young and old generations. In G1 GC, HotSpot introduces the concept of “regions”. A single large contiguous Java heap space divides into multiple fixed-sized heap regions. A list of “free” regions maintains these regions. As the need arises, the free regions are assigned to either the young or the old generation. These regions can span from 1MB to 32MB in size depending on your total Java heap size. The goal is to have around 2048 regions for the total heap. Once a region frees up, it goes back to the "free" regions list. The principle of G1 GC is to reclaim the Java heap as much as possible (while trying its best to meet the pause time goal) by collecting the regions with the least amount of live data i.e. the ones with most garbage, first; hence the name Garbage First.

[valchkou]

А думал за 5 лет вырастит целое поколение специалистов, способных без труда ответить на этот вопрос...
Впрочем never mind. Погуглю как-нибудь...

Ну вы даете. Вас же попросили тип коллектора уточнить
Для high throughput систем хорошо работает G1GC, но у него конечно свое понимание как оптимизировать процесс, а не просто "кога у меня для тебя есть CPU - тогда и включайся

не важно какой тип коллектора - все они в JVM запускаются по memory threshold а не по CPU availability, даже G1.
помнится был какой то коллектор который запускался по статистике. Т.е пытался угадать когда лучше.
Но опять же это не CPU\Resource availability.
В некоторых браузерах GC(не жава) как раз работает по CPU\Resource + memory threshold.
Оракл видимо решил не париться с этим.
В целом я пока доволен G1 коллектором (Hotspot java 8 ). Работает намного шустрее чем java 7 без настроек.
Главное не использовать OpenJDK, который идет по умолчанию на EC2 инстансах

[Palych]

Ну вы даете. Вас же попросили тип коллектора уточнить

Уточнить не могу. Я любопытствую - есть ли сейчас в Java a Garbage collector, который не расслабляется если свободной памяти много.

Для high throughput систем хорошо работает G1GC, но у него конечно свое понимание как оптимизировать процесс, а не просто "кога у меня для тебя есть CPU - тогда и включайся

The principle of G1 GC is to reclaim the Java heap as much as possible (while trying its best to meet the pause time goal) by collecting the regions with the least amount of live data i.e. the ones with most garbage, first; hence the name Garbage First.

Если я правильно понимаю: даже если памяти много, но мусор имеется - хотя бы один регион будет взят в работу...
Выходит - ответ на мой вопрос утвердительный...
Спасибо!

[Сабина]

Negative, коллекция идет такой же обычной пилой, нарастает до максимума памяти выставленного параметром и идет сборка гарбиджа. Конечно при условии чтотнет leaks and major screwups.
Я если честно не поняла мысли глубокой про CPU threshhold ? Вы не забывайте что коллекция тормозит перформанс самого приложения, вы предлагаете чтобы треды приложения вступили в борьбу с тредами гарбидж коллектора под лозунгом "обеспечь родине 80% free memory at all times" ? Зачем, кому от этого лучше ? Чтоб CPU ниже 95% не "простаивало" ?
Чай не глупые люди придумали как эту экосистему ресурсов и процессов построить и контролировать. Посмотрите какие там возможности тьюнинга накидали в последней джаве. Если в этом разбираться это все совсем не так банально как поставил Xmx и забыл

[Сабина]

сходите на сайт gceasy.io и скормите им какой нибудь свой GC log, G1GC интереснее.
много любопытного узнаете

[iDesperado]

не важно какой тип коллектора - все они в JVM запускаются по memory threshold а не по CPU availability, даже G1.

а какой физический смысл смотреть на CPU availability ? уже через долю секунды нагрузка изменится.

[metaller]

А думал за 5 лет вырастит целое поколение специалистов, способных без труда ответить на этот вопрос...
Впрочем never mind. Погуглю как-нибудь...

Ну вы даете. Вас же попросили тип коллектора уточнить
Для high throughput систем хорошо работает G1GC, но у него конечно свое понимание как оптимизировать процесс, а не просто "кога у меня для тебя есть CPU - тогда и включайся

G1 GC is an incremental parallel compacting GC that provides more predictable pause times compared to CMS GC and Parallel Old GC. By introducing a parallel, concurrent and multi-phased marking cycle, G1 GC can work with much larger heaps while providing reasonable worst-case pause times. The basic idea with G1 GC is to set your heap ranges (using -Xms for min heap size and -Xmx for the max size) and a realistic (soft real time) pause time goal (using -XX:MaxGCPauseMillis) and then let the GC do its job.

With the introduction of G1 GC, HotSpot moves away from its conventional GC layout where a contiguous Java heap splits into (contiguous) young and old generations. In G1 GC, HotSpot introduces the concept of “regions”. A single large contiguous Java heap space divides into multiple fixed-sized heap regions. A list of “free” regions maintains these regions. As the need arises, the free regions are assigned to either the young or the old generation. These regions can span from 1MB to 32MB in size depending on your total Java heap size. The goal is to have around 2048 regions for the total heap. Once a region frees up, it goes back to the "free" regions list. The principle of G1 GC is to reclaim the Java heap as much as possible (while trying its best to meet the pause time goal) by collecting the regions with the least amount of live data i.e. the ones with most garbage, first; hence the name Garbage First.

Использую G1 garbage collector для прожроливого desktop приложения. По ощущениям действительно обеспечивает более которкие паузы.