Обновляются ли ссылки, когда сборщики мусора перемещают данные в кучу?

Ответ 1

Да, ссылки обновляются во время сбора мусора. При необходимости объекты перемещаются при уплотнении кучи. Уплотнение служит двум основным целям:

• это делает программы более эффективными, используя кеширование данных процессора более эффективно. Это очень и очень много для современных процессоров, оперативная память чрезвычайно медленная по сравнению с движком исполнения, толстая на два порядка. Процессор может быть остановлен для сотен инструкций, когда ему нужно дождаться, когда ОЗУ предоставит переменное значение.
• он решает проблему фрагментации, от которой страдают кучи. Фрагментация происходит при выпуске небольшого объекта, окруженного живыми объектами. Отверстие, которое нельзя использовать ни для чего другого, кроме объекта с равным или меньшим размером. Плохо для эффективности использования памяти и эффективности процессора. Обратите внимание, что LOH, куча больших объектов в.NET, не уплотняется и, следовательно, страдает от этой проблемы фрагментации. Много вопросов об этом в SO.

Несмотря на то, что Eric didactic, ссылка на объект действительно является только адресом. Указатель, точно такой же, какой вы использовали бы в программе C или C++. Очень эффективно, обязательно так. И весь GC должен сделать после перемещения объекта, обновляет адрес, хранящийся в этом указателе на перемещенный объект. CLR также позволяет выделять дескрипторы объектов, дополнительные ссылки. Выставляется как тип GCHandle в.NET, но необходимо только в том случае, если GC нуждается в помощи, определяющей, должен ли объект оставаться в живых или его не следует перемещать. Имеет значение только если вы взаимодействуете с неуправляемым кодом.

Что не так просто - это найти этот указатель. CLR сильно инвестируется в обеспечение того, что можно сделать надежно и эффективно. Такие указатели могут храниться во многих разных местах. Более легкими для поиска являются ссылки на объекты, хранящиеся в поле объекта, статическая переменная или GCHandle. Жесткие - это указатели, хранящиеся в стеке процессора или регистре CPU. Например, для аргументов метода и локальных переменных.

Одна из гарантий, которую CLR должна обеспечить, чтобы это произошло, состоит в том, что GC всегда может надежно пройти стек потока. Таким образом, он может найти локальные переменные обратно, которые хранятся в фрейме стека. Тогда ему нужно знать, где искать такой фрейм стека, что работа компилятора JIT. Когда он компилирует метод, он не просто генерирует машинный код для метода, но также создает таблицу, которая описывает, где хранятся эти указатели. Более подробную информацию об этом вы найдете в этом посте.

Ответ 2

Глядя на C++\CLI В действии, есть раздел о внутренних указателях против указателей пиннинга:

C++/CLI предоставляет два типа указателей, которые работают вокруг этой проблемы. Первый вид называется внутренним указателем, который обновляется средой выполнения, чтобы отражать новое местоположение объекта, указывающее на каждый раз, когда объект перемещается. Физический адрес, на который указывает внутренний указатель, никогда не остается прежним, но он всегда указывает на тот же объект. Другой вид называется указателем пиннинга, который не позволяет GC переместить объект; другими словами, он связывает объект с определенным физическим местоположением в куче CLR. С некоторыми ограничениями возможны преобразования между внутренними, пиннинг и внутренними указателями.

Из этого вы можете сделать вывод, что ссылочные типы перемещаются в кучу, и их адреса меняются. После фазы Mark и Sweep объекты уплотняются внутри кучи, тем самым фактически переходя к новым адресам. CLR отвечает за отслеживание фактического местоположения хранилища и обновление этих внутренних указателей с использованием внутренней таблицы, следя за тем, чтобы при доступе он все же указывал на правильное местоположение объекта.

Вот пример, взятый отсюда:

ref struct CData
{
    int age;
};

int main()
{
    for(int i=0; i<100000; i++) // ((1))
        gcnew CData();

    CData^ d = gcnew CData();
    d->age = 100;

    interior_ptr<int> pint = &d->age; // ((2))

    printf("%p %d\r\n",pint,*pint);

    for(int i=0; i<100000; i++) // ((3))
        gcnew CData();

    printf("%p %d\r\n",pint,*pint); // ((4))
    return 0;
}

Это объясняется:

В образце кода вы создаете 100 000 объектов-сирот CData ((1)), чтобы вы могли заполнить хорошую часть кучи CLR. Затем вы создаете объект CData, который хранится в переменной, и ((2)) внутренний указатель на возраст члена этого объекта CData. Затем вы распечатываете адрес указателя, а также значение int, на которое указывает. Теперь ((3)) вы создаете еще 100 000 объектов-сирот-CData; где-то вдоль линии происходит цикл сбора мусора (объекты-сироты, созданные ранее ((1)), собираются, потому что они нигде не упоминаются). Обратите внимание, что вы не используете вызов GC :: Collect, потому что это не гарантирует принудительный цикл сбора мусора. Как вы уже видели в обсуждении алгоритма сбора мусора в предыдущей главе, GC освобождает пространство путем удаления объектов-сирот, чтобы он мог выполнять дальнейшие распределения. В конце кода (к тому времени произошла сборка мусора), вы снова ((4)) распечатаете адрес указателя и значение возраста. Это результат, который я получил на своей машине (обратите внимание, что адреса будут отличаться от машины к машине, поэтому ваши выходные значения не будут одинаковыми):

012CB4C8 100
012A13D0 100