Почему сборщики мусора замораживают выполнение?
Простой способ чтения файлов cookie в ES6.
function getCookies() {
var cookies = {};
for (let cookie of document.cookie.split('; ')) {
let [name, value] = cookie.split("=");
cookies[name] = decodeURIComponent(value);
}
console.dir(cookies);
}
4 ответа
Современные сборщики мусора (в .NET и Java, по крайней мере) на самом деле не «останавливают мир» - они делают всевозможные умные вещи для одновременного сбора.
Однако вы можете хотите рассмотреть такую ситуацию:
object x = null;
object y = new object();
...
x = y;
y = null;
Теперь предположим, что сборщик мусора смотрит на x , а затем на строки под ... run, а затем сборщик мусора смотрит на y - он не видел никаких живых объектов ... но объект должен все еще быть живым.
В основном он должен быть определенное количество пауз для получения согласованного набора ссылок. Затем идет уплотнение, переназначение ссылок и т. Д. Однако это не так плохо, как раньше, с точки зрения требования остановки всего на протяжении всего цикла сборки мусора. Это делает , однако,
В дополнение к тому, что сказал Кико Лобо, сборщики мусора также могут перемещать объекты в памяти.
Следовательно, они должны блокировать не только потоки, которые пишут в память, но и потоки которые читаются из памяти.
То есть каждый поток.
Большинство сборщиков мусора останавливают выполнение, потому что объекты могут перемещаться в памяти во время цикла сбора (по крайней мере, с наиболее разумно недавними проектами). Это означает, что чтение или запись почти любого объекта в неподходящее время может вызвать проблему.
Существуют коллекторы, которые были разработаны на основе идеи простой блокировки чтения (или записи) в определенные части памяти, изменяемые в заданное время. время, поэтому, пока выполнение использует только те объекты, которые (в настоящее время) не перемещаются, оно может продолжаться беспрепятственно. Проблема в том, что наиболее типичное оборудование не обеспечивает для этого эффективной поддержки, поэтому, хотя они в принципе работают, на практике они довольно неэффективны. Была по крайней мере одна попытка адаптировать этот тип алгоритма для использования защиты от записи, доступной в типичном модуле подкачки, но я ' Я не знаю, что он использовался для чего-то другого, кроме исследований и экспериментов.
Основная альтернатива - сделать сборщик инкрементальным , то есть заставить его выполнять только небольшой объем работы за раз, поэтому, даже если другое выполнение останавливается, оно должно останавливаться только на короткое время в любой момент времени.
Однако, когда многоядерные машины становятся настолько распространенными, я ожидаю увидеть больше работы, вложенной в алгоритмы сборки мусора, которые может работать параллельно с другим исполнением. До недавнего времени основной упор делался на минимизацию общего времени / усилий, затрачиваемых на сборку мусора. Растущее количество доступных ядер может (часто) означать, что выполнение большего объема работы по сборке мусора может быть легко оправдано, если это позволяет основной части кода работать с меньшими препятствиями.
Изменить: Возможно, вы захотите прочитать Обзор методов сбора мусора однопроцессорных систем Пола Уилсона . Это не является окончательным (особенно, учитывая его возраст), но это, по крайней мере, разумная отправная точка.
Потому что это единственный способ гарантировать, что референсы, которые он собирается очистить, не использовались кем-либо еще.
Если бы он не остановил выполнение, он не смог бы этого гарантировать.