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

Я читал, что GC (сборщик мусора) перемещает данные в куче по соображениям производительности, но я не совсем понимаю, почему, поскольку это память с произвольным доступом, возможно, для лучшего последовательного доступа, но мне интересно, обновляются ли ссылки в стеке при таком перемещении в куче. Но, возможно, адрес смещения остается тем же, но другие части данных перемещаются сборщиками мусора, хотя я не уверен.

Я думаю, что этот вопрос относится к деталям реализации, поскольку не все сборщики мусора могут выполнять такую ​​оптимизацию, или они могут делать это, но не обновлять ссылки (если это является обычной практикой среди реализаций сборщика мусора). Но я хотел бы получить общий ответ, специфичный для сборщиков мусора CLR (Common Language Runtime).

А также я читал статью Эрика Липперта "Ссылки не адреса"Воти следующий абзац немного смутил меня:

Если вы думаете, что ссылка на самом деле является непрозрачным дескриптором GC, тогда становится ясно, что для поиска адреса, связанного с дескриптором, вы должны каким-то образом «исправить» объект. Вы должны сказать GC «до дальнейшего уведомления, объект с этим дескриптором не должен перемещаться в памяти, потому что кто-то может иметь внутренний указатель на него». (Существуют различные способы сделать то, что выходит за рамки этой стяжки.)

Это похоже на ссылочные типы, мы не хотим, чтобы данные были перемещены. Тогда что еще мы храним в куче, которую мы можем перемещать для оптимизации производительности? Может быть, тип информации мы храним там? Кстати, если вам интересно, о чем эта статья, то Эрик Липперт немного сравнивает ссылки на указатели и пытается объяснить, как может быть неправильно говорить, что ссылки - это просто адреса, даже если C # реализует их.

А также, если какое-либо из моих предположений выше неверно, пожалуйста, исправьте меня.

Ответы на вопрос(2)

Ваш ответ на вопрос