maytonА вот более конкретна бумажка по этому "взрывному" мусорщику https://www.azul.com/files/c4_paper_acm1.pdf

График летенси сборщика мусора Go Runtime 1.6 сферического приложения в вакууме.

mayton,

Да. Он самый Go.

nojavaи в чем твой ненагноящийся спич? что java поделки могут запускаться только или на физическом железе или с жестко зааллоцированными параметрами размера предаллоцированной памяти?

Это не соответствует действительности.
Тот же Netflix тысячи своих джава поделок на EC2, Google запускает тысячи своих джава приложений на виртуалках и не жужжат.

maytonschwamayton,

Да. Он самый Go.
Положа руку на серде я уже потерял корень дискусси по поводу GC.
Но если мы будем обсуждать GC in General то ОК. Я согласен.

Давайте обсуждать генерализованные GC в Lisp, .Net, DLang, Golang
и их общие алгоритмы и подходы.
Возвращаясь к java.
В ввиду того, что

1) писатели всякого "миддлваре" на джаве (кассандра, и тп) додумались, что хранить данные своих колоночек/столбцов/очередей и тп в хипе, не очень хорошая идея.
2) тем, кому нужны какие-то вменяемые данные по лейтенси, тоже не особо наделяется на GC.
Большинство решений, которым нужно эффективное управление памятью, пишут это управление сами.
3) Перед тем как тюнить сборку мусора надо посмотреть профиль аллокаций в профайлере и исправить кучу мест, где аллокации нафиг не сдались... потом может оказаться что и тюнить сборку мусора не надо т.к. ,если у нас генерейшанл GC, например, никто не промоутится

Young Generation GC это хорошо (хотя если написать код так, чтобы она была не нужна, то лучше так и сделать), сборка старого поколения очень очень плохо.

maytonschwaПеред тем как тюнить сборку мусора надо посмотреть профиль аллокаций в профайлере и исправить кучу мест, где аллокации нафиг не сдались... потом может оказаться что и тюнить сборку мусора не надо т.к. ,если у нас генерейшанл GC, например, никто не промоутится

Young Generation GC это хорошо (хотя если написать код так, чтобы она была не нужна, то лучше так и сделать), сборка старого поколения очень очень плохо.
1) Я рискну предположить что сами по себе аллокации не страшны (работа стека это тоже аллокация в некотором смысле)
но страшны ссылки которые пережили 1-ю эпоху чистки. Работать без аллокаций вообще невозможно - это равносильно
отказу от работы со строковым типом данных. Везде где строки - будут аллокации.

От строк избавиться-то можно (самопильные оффхип строки кое-где используются), а от копирования байт при передаче на запись в файл/сокет уже не получится.

mayton2) По поводу тюнига сборки мусора. Нет ли здесь отсылки к разработкам LMAX? ЕМНИП из лекций по
неблокирующим очередям некто рассказывал что дескыть отключали вообще GC на сутки и при
этом утечки были так соптимизированы что в качесте уборки использовали просто ежесуточный
ребут сервера (нормальный график работы Лондонской биржи).
Это известный сценарий, когда _все_ создаваемые объекты "всегда умирают молодыми". Если у вас такое приложение, то можно выделять большой-большой массив объектов и его элементы переиспользовать т.к. размер старого поколения в вас не изменяется, то сборок старого поколения нет и вот у вас GC пауза порядка 5 ms и меньше в зависимости от интенсивности создания молодых объектов. Если же нет, то все становится намного интересней.