6 записей с тегом "память"

Этот блог-пост подготовлен Хосе Дапена Пазом (Igalia) при содействии Джейсона Уильямса (Bloomberg), Эшли Клеймора (Bloomberg), Роба Пальмера (Bloomberg), Джойи Чюн (Igalia) и Шу-Юй Гуо (Google).

В этом посте о снимках кучи V8 я расскажу о некоторых проблемах производительности, обнаруженных инженерами Bloomberg, и о том, как мы их решили, чтобы сделать анализ памяти JavaScript быстрее, чем когда-либо.

Проблема​

Инженеры Bloomberg работали над диагностикой утечки памяти в JavaScript-приложении. Оно завершалось с ошибками Out-Of-Memory. Для тестируемого приложения предел кучи V8 был настроен примерно на 1400 МБ. Обычно сборщик мусора V8 должен быть способен удерживать использование кучи ниже этого предела, поэтому сбои указывали на вероятную утечку.

Это абсолютно глупо иметь 64-битные указатели, когда я компилирую программу, использующую менее 4 гигабайт оперативной памяти. Когда такие значения указателей оказываются внутри структуры, они не только занимают половину памяти, но и фактически используют лишь половину кеша.

– Дональд Кнут (2008)

За последние годы сборщик мусора (GC) в V8 сильно изменился. Проект Orinoco преобразовал последовательный сборщик мусора с полной остановкой мира в в основном параллельный и конкурентный сборщик с плановой обратной связью.

Примерно три месяца назад я начала работать в команде V8 (Google Munich) в качестве стажера и с тех пор занимаюсь дезоптимизатором виртуальной машины — задачей, которая была для меня абсолютно новой, но оказалась интересной и сложной. Первая часть моей стажировки была направлена на улучшение безопасности виртуальной машины. Вторая часть касалась повышения производительности, а именно удаления структуры данных, используемой для отмены оптимизации функций, которая была узким местом для производительности при сборке мусора. В этой записи блога я описываю вторую часть своей стажировки, объясняя, как V8 раньше удалял неактивные функции, как мы это изменили и какие улучшения производительности были достигнуты.

V8 имеет жесткий лимит на размер своей кучи. Это служит защитным механизмом против приложений с утечками памяти. Когда приложение достигает этого жесткого лимита, V8 выполняет серию последнего шанса сборок мусора. Если сборки мусора не помогают освободить память, V8 прекращает выполнение и сообщает об ошибке недостатка памяти. Без жесткого лимита приложение с утечкой памяти могло бы использовать всю системную память, что повредило бы производительность других приложений.

В предыдущем посте в блоге мы рассмотрели проблему джанка, вызванного сборкой мусора, которая прерывает плавный процесс просмотра. В этом посте мы представляем три оптимизации, которые являются основой для нового сборщика мусора в V8, кодовое название которого — Orinoco. Orinoco основан на идее реализации преимущественно параллельного и конкурентного сборщика мусора без строгих границ поколений, что позволит уменьшить джанк от сборки мусора и снизить потребление памяти, обеспечивая при этом высокую пропускную способность. Вместо того чтобы реализовывать Orinoco в виде отдельного сборщика мусора с флагом, мы решили постепенно вводить его функции в основной ветке V8, чтобы пользователи могли сразу извлечь из этого пользу. Три функции, обсуждаемые в этом посте, — это параллельная компактация, параллельная обработка запомненного набора и черное выделение.