Необходимый объем памяти зависит от скорости выделения в вашей программе.Если у вас высокий уровень распределения, вам нужно больше места для роста, пока GC работает.
Другой фактор - время жизни объекта.Если ваши объекты обычно имеют очень короткий срок службы, то вы можете справиться с немного меньшим запасом времени с помощью коллектора поколений.
Существует множество исследовательских работ, которые могут вас заинтересовать.Я отредактирую немного позже, чтобы сослаться на некоторые из них.
Редактировать (январь 2011 г.):
Я думал о конкретной статье, которую, похоже, не могу найтипрямо сейчас.Те, что ниже, интересны и содержат некоторые важные данные о производительности.Как правило, у вас, как правило, все в порядке примерно с вдвое большим объемом доступной памяти, чем у вашей резидентной программы.Некоторым программам нужно больше, но другие программы будут работать очень хорошо даже в стесненных условиях.Есть много переменных, которые влияют на это, но скорость выделения является наиболее важной.
Immix: сборщик мусора в области меток с эффективным использованием пространства, быстрым сбором и мутаторомпроизводительность
Мифы и реальность: влияние на производительность сборки мусора
Редактировать (февраль 2013 г.): Это изменение добавляетсбалансированный подход к цитируемой статье, а также устранение возражений, высказанных Тимом Купером.
Количественная оценка производительности сборки мусора и явного управления памятью ,как отметил Натан Йеллин, на самом деле это ссылка, которую я впервые пытался вспомнить еще в январе 2011 года. Однако я не думаю, что интерпретация, предложенная Натаном, верна.Это исследование не сравнивает GC с обычным ручным управлением памятью.Скорее он сравнивает GC с оракулом, который делает совершенные явные выпуски.Другими словами, это заставляет нас не знать, насколько хорошо обычное ручное управление памятью по сравнению с волшебным оракулом.Это также очень трудно выяснить, потому что исходные программы написаны либо для GC, либо для ручного управления памятью.Таким образом, любой эталонный тест сохраняет присущую ему предвзятость.
Следуя возражениям Тима Купера, я хотел бы прояснить свою позицию по вопросу о запасе памяти.Я делаю это главным образом для потомков, так как я считаю, что ответы переполнения стека должны служить многолетним долгосрочным ресурсом.
В типичной системе GC много областей памяти, но есть три абстрактных вида:
- Выделенное пространство (содержит живые, мертвые и неотслеживаемые объекты)
- Зарезервированное пространство (из которого выделяются новые объекты)
- Рабочая область (долгосрочная и краткосрочнаятермин GC структуры данных)
Что такое запас в любом случае?Запас хода - это минимальный объем зарезервированного пространства, необходимого для поддержания желаемого уровня производительности. Я полагаю, что именно об этом спрашивал ОП. Вы также можете думать о запасе памяти как о памяти, необходимой для фактического резидентного расположения программы (максимальной оперативной памяти), необходимой для хорошей производительности.
Да -- увеличение запаса может задержать сборку мусора и увеличить пропускную способность.Это важно для автономных некритических операций.
В действительности большинство проблемных областей требуют решения в реальном времени.Существует два вида реального времени, и они очень разные:
- для жесткого реального времени - наихудшая задержка (для критически важных систем) - поздний ответ от распределителя является ошибкой.
- soft-realtime относится к средней или средней задержке - поздний ответ от распределителя в порядке, но не должен происходить часто.
Большинство современных сборщиков мусора нацелены на программный режим реального времени, который хорош как для настольных приложений, так и для серверов, которые предоставляют услуги по требованию.Если кто-то исключает реальное время как требование, он также может использовать сборщик мусора «останови мир», в котором запас начинает терять смысл.(Примечание: приложения с преимущественно недолговечными объектами и высокой скоростью выделения могут быть исключением из-за низкой выживаемости.)
Теперь предположим, что мы пишем приложение, которое имеет требования мягкого реального времени.Для простоты предположим, что GC работает одновременно на выделенном процессоре.Предположим, что программа обладает следующими искусственными свойствами:
- средняя резидентность: 1000 КБ
- зарезервированный запас: 100 КБ
- Продолжительность цикла ГХ: 1000 мс
А:
- скорость выделения A: 100 КБ / с
- скорость выделения B: 200 КБ / с
Теперь мы можемсм. следующую временную шкалу событий со скоростью распределения A:
- T + 0000 мс: цикл GC начинается, 100 КБ доступно для распределений, 1000 КБ уже выделено
- T + 1000 мс:
- 0 КБ свободного места в зарезервированном пространстве, 1100 КБ выделено
- цикл GC завершен, освобождено 100 КБ
- 100 КБ свободно в резерве, 1000 КБ выделено
- T + 2000 мс: то же, что и выше
Временная шкала событий со скоростью выделения B отличается:
- T + 0000 мс: цикл GCзапускается, 100 КБ доступно для выделения, 1000 КБ уже выделено
- T + 0500 мс:
- 0 КБ свободно в зарезервированном пространстве, 1100 КБ выделено
- либо
- задержка до конца цикла GC (плохая, но иногда обязательная), либо
- увеличение зарезервированного размера до 200 КБ со свободными 100 КБ (предполагается здесь)
- T + 1000 мс:
- 0 КБ свободно в зарезервированном пространстве, выделено 1200 КБ
- цикл GC завершен, выпущено 200 КБ
- 200 КБ свободно в резерве, 1000 КБ выделено
- T + 2000 мс:
- 0 КБ свободно в зарезервированном пространстве, 1200 КБ выделено
- Цикл GC завершен, выпущено 200 КБ
- 200 КБ, свободен в резерве, выделено 1000 КБ
Обратите внимание, как скорость распределения напрямую влияет на размер запасатребуется?При уровне распределения B нам требуется вдвое больше запаса для предотвращения пауз и поддержания того же уровня производительности.
Это был очень упрощенный пример, предназначенный для иллюстрации только одной идеи. Есть много других факторов, но это показывает, что было задумано.Имейте в виду другой важный фактор, который я упомянул: среднее время жизни объекта.Короткое время жизни приводит к тому, что низкие показатели выживаемости, которые работают вместе со скоростью выделения, влияют на объем памяти, необходимый для поддержания заданного уровня производительности.
Короче говоря, нельзя делать общие заявления о требуемом запасе, не зная ипонимание характеристик приложения.