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 приложения. По ощущениям действительно обеспечивает более которкие паузы.

[Palych]

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

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

Понятно что нужен компромисс, но если смотреть на память и ничего не делать если её достаточно - становится невозможно определить сколько нужно памяти и сколько её используется.
А если выделить слишком много - есть риск что не хватит времени разобрать большую кучу к тому времени как место понадобится.

[Palych]

А как с этим в .Net?
Там тоже с бубном пляшут настраивая сборщики мусора?

[valchkou]

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

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

CPU availability возможно не совсем точное определение, но тут нет ничего удивительного
К примеру V8 javascript GC использует данную концепцию
" Idle Time Garbage Collection Scheduling"

V8 posts idle tasks to the scheduler in order to perform both minor and major garbage collection during idle time

[valchkou]

А как с этим в .Net?
Там тоже с бубном пляшут настраивая сборщики мусора?

палыч, расскажи зачем ты бубном пляшешь, что у тебя за usecase?
java 8 великолепно работает из коробочки без бубнов. Ну если только размер памяти задать побольше

[iDesperado]

CPU availability возможно не совсем точное определение, но тут нет ничего удивительного
К примеру V8 javascript GC использует данную концепцию
" Idle Time Garbage Collection Scheduling"

V8 posts idle tasks to the scheduler in order to perform both minor and major garbage collection during idle time

As soon as an incremental major garbage collection is started, V8 posts an idle task to Chrome's task scheduler, which will perform incremental marking steps. These steps can be linearly scaled by the number of bytes that should be marked. Based on the average measured marking speed, the idle task tries to fit as much marking work as possible into the given idle time. The idle task keeps reposting itself until all live objects are marked. V8 then posts an idle task for finalizing the major garbage collection..

как я понимаю idle time это время между major garbage collection, которое четко задается.

[Flash-04]

java 8 великолепно работает из коробочки без бубнов. Ну если только размер памяти задать побольше

за всё надо платить: чем больше памяти, тем больше GC прибираться, тем дольше оно работает, тем дольше всё стоит и ждёт во время цикла уборки.

[Palych]

java 8 великолепно работает из коробочки без бубнов. Ну если только размер памяти задать побольше

за всё надо платить: чем больше памяти, тем больше GC прибираться, тем дольше оно работает, тем дольше всё стоит и ждёт во время цикла уборки.

Вот-вот, при определённых условиях возникает лавинный эффект, и приложение встаёт колом (я это видео на java 6 в сочетании с глюком в jboss vfs)

А главное: "побольше" - это сколько?
Я знаю что интенсивный анализ требований к памяти новых приложений заканчивается выводом: "А сколько у вас есть? Вот и выделяйте всю. Только не забудьте Xms поставить такой-же как Xmx"... а потом админы утверждаются во мнении "Жаба жрет память как свинья помои".

Мне любопытно изменилось ли что-то за последние годы

[anarchist]

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

А где написано про 70%? У меня так сейчас под Жава6 и на 80% не срабатывает, где то 90% доходит, потом жах.

[valchkou]

за всё надо платить: чем больше памяти, тем больше GC прибираться, тем дольше оно работает, тем дольше всё стоит и ждёт во время цикла уборки.

Вот-вот, при определённых условиях возникает лавинный эффект, и приложение встаёт колом (я это видео на java 6 в сочетании с глюком в jboss vfs)

мужики да вы сначала попробуйте, палыч, какой жава 6, это что вообще?
вот слушает молодежь вас и думает что жава это гавно. и вместо жавы начинает изучать гавно.
времена изменились, теперь и железки другие и GC и сама жава.
все летает и на 1 гиге и на 12 и на 32х, никаких долгих пауз, милисекунды.
Запустите, поиграйтесь, посмотрите статистику, и уверяю вас вы будете приятно удивлены

[anarchist]

за всё надо платить: чем больше памяти, тем больше GC прибираться, тем дольше оно работает, тем дольше всё стоит и ждёт во время цикла уборки.

Вот-вот, при определённых условиях возникает лавинный эффект, и приложение встаёт колом (я это видео на java 6 в сочетании с глюком в jboss vfs)

мужики да вы сначала попробуйте, палыч, какой жава 6, это что вообще?
вот слушает молодежь вас и думает что жава это гавно. и вместо жавы начинает изучать гавно.
времена изменились, теперь и железки другие и GC и сама жава.
все летает и на 1 гиге и на 12 и на 32х, никаких долгих пауз, милисекунды.
Запустите, поиграйтесь, посмотрите статистику, и уверяю вас вы будете приятно удивлены

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

maximum heap size
"Smaller of 1/4th of the physical memory or 1GB. Before Java SE 5.0, the default maximum heap size was 64MB. You can override this default using the -Xmx command-line option."
https://docs.oracle.com/javase/8/docs/t ... omics.html" onclick="window.open(this.href);return false;