Как при сборки мусора и перемещении объекта, сохраняется корректность ссылок?

Question

[Даниил]

Я чет-то не могу найти, каким образом сохраняется корректность ссылок.
Везде где читаю, этот момент пропускается

int[]arr=new[100000000000000000000000000000000000000000]
 arr1=arr;
arr2=arr;
arr3=arr;
....  триллион раз и триллион кода

Теперь где-то, сборщик мусора, начинает переносить arr в другое место.
Вопрос, как об этом узнают другие ссылки?
Тут 2 способа на ум сразу.
Первый, типа взять, и каждому указателю обновить значения. Долго.
Второй. Сделать, промежуточный массив, который будет хранить адреса объектов. А любая ссылка, и любое разыменование объекта, будет проходить, через этот массив, как двойной указатель **. И когда объект перемещается, то обновляется его адрес в этом массиве.
Тогда итог, что языки с сборщиком мусора, под в 2 раза медленнее должны быть.(помимо сборки) Или есть какой еще способ.

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

Answer 1

[Сергей Соловьев]

Управление памятью в .NET для профессионалов

Как работает сборка мусора.
В .NET используется 2 фазная сборка мусора: Mark & Sweep (Пометить и Убрать).

Mark

На этом этапе обходится весь граф объектов. И выявляются все недостижимые.

Каким образом достижимость объектов определяется?

Достижимые это:
- Аллоцированные на стеке
- В статических полях
- Достижимые из достижимых (см. выше)

Все объекты, которые не удалось достичь (в граф не попали) - являются недостижимыми.

Но на стеке лежат числа. могут быть как числами, так и адресами, как и числами?

JIT копилятор достаточно умный, чтобы сгенерить код, который будет знать, что за объект/ссылка лежит на стеке. Так и получаются знания об объектах.

Sweep

Тогда итог, что языки с сборщиком мусора, под в 2 раза медленнее должны быть.(помимо сборки)

Вот тут интереснее. Есть несколько хаков как достигается большая производительность.
1. Линеризованное пространство памяти.
Адреса 0, 1 и 2 поколения расположены не абы где, а последовательно, друг за другом. Т.е. если нужно сократить пространство 0 поколения, то это означает простое передвигание указателя влево.

2. Переход в след. поколение происходит не всегда
Из 0 в 1 - переход быстрый, но из 1 в 2 - не всегда.
На этом этапе тоже может не затрачиваться много времени.

3. Ссылки из недостижимых объектов не обновляются - эти объекты и так нигде не участвуют
Обновление ссылок, к сожалению, - это ручное изменение и копирование. Ничего не поделаешь.

Теперь где-то, сборщик мусора, начинает переносить arr в другое место.

Ты слишком большой массив выделил, он аллоцируется в LOH. Оттуда не вытащишь.

Я много о чем не упомянул. Например, очередь финализации, таблица дескрипторов (Handle), сегментирование памяти и т.д. но ответы на основные вопросы дал

Comments

[Василий Банников]

В LOH* и такие большие объекты не двигабт в памяти, да.

[Сергей Соловьев]

Василий Банников, да, ошибочка. Спасибо за исправление

Answer 2

[Сергей Горностаев]

https://habr.com/ru/articles/269621/
https://habr.com/ru/articles/269707/
https://habr.com/ru/articles/269863/
https://habr.com/ru/articles/681116/
https://habr.com/ru/articles/680038/
https://habr.com/ru/articles/680038/
https://habr.com/ru/articles/681256/

Answer 3

[Роман]

Там выше посоветовали книгу Конрада Кокосы, добавлю от себя книгу Саши Гольдштейна и у Станислава Сидристого есть недописанная книга. Еще на ютубе с dotNext`а можно посмотреть, что то было интересного про внутненности dotnet`а.

Answer 4

[mayton2019]

Нету никаких указателей. Указатели - это терминология С++.

Да GC обладает правом двигать объекты в памяти. Но это тебя не должно волновать.
Ты работаешь в прарадигме managed memory.

Тость НИКАКОЙ АДРЕСНОЙ арифметики ты не имеешь права использовать.
Используй ссылки объекты и все будет норм.

Comments

[MVV]

Упрощаете, и IMHO чрезмерно.
Однако по жизни указатели, как сохраненные в памяти адреса объектов, таки есть. И даже в языке C# - есть, в unsafe context.
Другое дело, что на уровне абстракции управляемого кода и управляемой памяти, на котором работает громадное большинство программистов на C#, всё это скрыто от глаз.
Но как только возникает необходимость выйти за пределы этой абстракции (для использования системных вызовов или внешних библиотек с неуправляемым кодом), там требуются и указатели, и фиксированные или "пришпиленные" (pinned) объекты, на которые эти указатели указывают.
PS Ну, а про управление памятью в .NET есть целая книга за авторством Конрада Кокосы (на русский язык переведена). В ней много букв, но все они - полезные.

[mayton2019]

MVV, знаешь как в банках говорят должникам? Надо читать договор. Особенно то что прописано мелким шрифтом. Я давно не кодил в .net. Больше 10 лет. Но если я щас полезу в документацию. Там будет написано про unsafe context что-то вроде ИЛИ-ИЛИ. Или сборка мусора не работает. Или работает но адресную арифметику ты не будешь использовать.

[MVV]

mayton2019, ну, за 10 лет появился stackalloc. И даже, ЕМНИП был момент, когда Span ещё не завезли, что приходилось с размещенной через stackalloc памятью работать через указатели. Но для работы с объектами в куче через указатели, действительно, эти объекты надо фиксировать, а не надеяться на какое-то недокументированное поведение сборщика мусора (в конце концов, оно может поменяться без уведомления). Впрочем, и из этого правила есть исключение: можно указать и подготовить участок кода, на котором распредилитель памяти (и, следовательно, сборщик мусора) вызывать запрещено.
Но главная причина предыдущего ответа вам - в том, что автор хотел узнать, как оно работает внутри, за пределами абстракции управляемой памяти, а вы ему сразу начали писать, что он об этом спрашивать не должен: типа, это не его дело.

[Василий Банников]

mayton2019, сборка мусора работает и адресную арифметику можно использовать. Но адрес managed объекта можно узнать только запинив его.

[mayton2019]

Давайте вернемся к вопросу автора. Он спрашивает

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

[Василий Банников]

mayton2019, никак не узнают, тк ссылки тупые

Answer 5

[Василий Банников]

Если ты не используешь unsafe, то сборщик мусора сам все ссылки после передвижения поправит - ради этого он все managed потоки останавливает.

Если ты используешь unsafe и передаёшь куда-то сырые указатели, то тогда тебе надо запинить объект чтобы гарантировать, что объект не будет перемещаться. Для этого, например, есть конструкция fixed, но оно работает только в рамках блока и одного потока.