> Ну давай расскажи как быстро сборщик мусора освободит пару гигов когда памяти
> уже совсем нет, а вот очень прям сейчас надо.Если у тебя кончилась память, то тебе уже ничто не поможет. Ни сборщик мусора, ни его отсутствие. Причём обсуждая абстрактную программу нельзя даже сказать, когда быстрее кончится память -- в случае со сборщиком мусора или без него. Отсутствие сборщика мусора может сильно фрагментировать память, и кончаться тем, что половина 16 гигов памяти свободна, но невозможно выделить килобайт последовательной памяти.
> Сборщик мусора порождает тормоза в любой непредсказуемый момент времени для
> тяжелых приложений.
Не в любой, а тогда когда программист позволит. И нельзя сказать, чтоб так уж в непредсказуемый: это от сборщика мусора зависит, его поведение может быть более или менее предсказуемым. Например, он может не останавливать мир в периоды пиковых нагрузок.
Кроме того, что в твоём понимании "тяжёлое приложение"? Это то, которые активно работает с кучей, выделяя и освобождая, при этом выделяет куски памяти очень разных размеров (различающихся на несколько порядков) и куски памяти очень разной продолжительности жизни (опять же с разницей в несколько порядков)? Такой программе, даже если ей очень хочется real-time'а, я бы очень порекомендовал задуматься о том, как бы так адаптировать сборку мусора и использовать её. Иначе придётся покупать оперативки на порядок больше, чем будет пиковая сумма размеров объектов. Статическое управление памятью дефрагментирует кучу -- есть техники, которые позволяют снизить фрагментацию, но -- хыхы, -- чем навороченнее эти техники, тем дороже будет вызов free. Причём непредсказуемо дороже, то есть не удастся заранее предсказать сколько по времени будет выполняться free.