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