Как понять "перемещение объектов, непосредственно достижимых из запущенного кода"?

Question

Я изучаю вопрос интеграции gc в мой проект llvm, и когда я прочитал этот документ , меня смутило одно предложение:

Однако для сборщика, который пожелаетчтобы переместить объекты, непосредственно достижимые из выполняющегося кода, требуется более высокий стандарт.

Я не понимаю, что такое движение "перемещать объекты, достижимые непосредственно из выполняющегося кода", пытается сделать.

Для моей информации, понятие «перемещение» означает, что указатель gc ссылается на новое местоположение объекта, например:

в Java:

Foo foo = new Foo();

foo = new Foo(); // ---> a relocation happens

Так может кто-нибудь объяснить, что"перемещать объекты, непосредственно достижимые из выполняющегося кода", пытаясь это сделать?

Редактировать:

Что касается понятия "перемещение", документ не объясняет его, но я нашел этот документ , это компилятор для dotnet, который реализован llvm, он объяснил эту концепцию:

Алгоритм GC перемещается, если во время GC указатели GC могут обновляться для ссылки на новыйместонахождение объекта. Указатели обновления алгоритма найдены в определенных регионах, но не в других. Например, указатели GC из стека могут не обновляться, а указатели GC в куче могут быть обновляемыми. Если алгоритм перемещает указатели из всех регионов, он полностью перемещается. Когда GC перемещает указатели из некоторой области памяти, это обязательно означает, что отчеты GC являются точными в этой области.

Я не знаю, правильно ли я понимаю «перемещение», поэтому я вставляю это дляВаша информация.

Answer 1

Это означает перемещение объекта, адрес которого находится в локальной функции-переменной. Например:

void doRelevantActions(final Thing t) {
    for(Aspect a : t.getAspects())
        if(a.isRelevant(getCurrentSituation()))
            t.doSomeAction();
}

Обычно Aspect достижимо только из Thing. Но в этом цикле локальная переменная a также достигает значения Aspect и a, вероятно, находится в регистре ЦП, поэтому ГХ, возможно, придется изменить значение регистра ЦП, чтобы переместить это Aspect.

Модификация регистров ЦП функции во время работы требует больше, чем "более высокий стандарт", по моему мнению. Это требует волшебной палочки.

Я полагаю, что GC, которые делают подобные вещи, делают это, гарантируя, что в некоторых точках нет состояний в регистрах ЦП, поэтому останавливая работающий поток и изменяя всекадров стека потока достаточно для перемещения объектов. Однако модификация стековых фреймов не совсем простая задача.

РЕДАКТИРОВАТЬ: Может быть, я неправильно понял суть вашего вопроса? Может быть, вам действительно интересно, что такое переезд? Предположим, что объект имеет размер 100 байт и что в какой-то момент он один занимает страницу ОЗУ емкостью 8 КБ, поскольку на этой странице больше ничего недоступно. Если GC может переместить этот 100-байтовый объект на другую страницу 8 КБ, он может освободить 8 КБ. Эта операция называется перемещением.

Answer 2

В этом случае в статье говорится о перемещении объектов в куче, а не из вашего кода.

Существует множество различных алгоритмов GC, поэтому давайте использовать HotSpot с G1 в качестве примера.

Куча делится на две логические области (поколения), молодые и старые. Молодое поколение собрано дешево, потому что пространство Эдема рассматривается как стек. Когда происходит второстепенный сборщик мусора, объекты копируются из Эдема в пространство выживших (все еще в молодом поколении). Это перемещение объекта, перемещение его из одной части кучи в другую. Объекты также копируются из одного пространства выживших в другое, пока не будет достигнут порог владения. Затем они копируются в старое поколение, если на него все еще ссылаются.

Для основного цикла GC объекты перемещаются в старое поколение, чтобы уменьшить фрагментацию свободного пространства.

Доступ к объектам осуществляется череззаголовок объекта, который содержит адрес в куче, где в данный момент хранится объект. Во время перемещения заголовок объекта необходимо обновить, чтобы убедиться в его правильности. Для этого необходимо, чтобы заголовок объекта был заблокирован, что блокирует потоки приложения во время обновления. Многие алгоритмы GC группируют все эти обновления вместе, что приводит к паузам GC, которые могут быть видны.

Другие алгоритмы, такие как C4 в Zing from Azul (для которого я работаю), используют барьер чтения на объекте. заголовок для устранения GC пауз. Если вы хотите больше подробностей, вы можете прочитать статью здесь http://go.azul.com/continuously-concurrent-compacting-collector