👀🗑Сборка мусора в Unity? Часть 5 Продолжаем по сборщику мусора. 🤬Я в придачу еще и заболел. Не обессудьте, но посты пока реже. Врываемся с двух ног. Так как, наконец, переходим к самому процессу сборки. Немного заумный текст, но полезно ознакомиться. Из первой статьи мы знаем, что вторая фаза — это фаза маркировки. С неё мы и начинается сборка. На этой фазе Boehm GC отмечает все объекты, к которым можно получить доступ через цепочки указателей на переменные. Представляйте это как деревья. Деревья ссылок на разные места памяти. Этот алгоритм, по простому, обходит деревья и расставляет ссылки, что объекты являются досигаемыми. Но рассмотрим глубже: В hblkhdr — HBLK хедере — хранится информация о ссылающихся объектах. (Отсылаю на статьи выше). Сначала вызывается метод GC_clear_marks для сброса всех битов маркировки. Метод GC_apply_to_all_blocks — перебирает адреса всех блоков памяти HBLK и находит нужные заголовки. И метод внутри —GC_stopped_mark. Что он делает? Он реализует основную логику сканирования. Вставлю вначале фрагмент кода, убрав лишнее. if(GC_on_collection_event) GC_on_collection_event(GC_EVENT_POST_STOP_WORLD); // Событие о приостановке мира. STOP_WORLD(); // Приостановить поток. if(GC_on_collection_event) GC_on_collection_event(GC_EVENT_MARK_START); // Начало маркировки. if (GC_mark_some(GC_approx_sp())) break; // Маркировка с корня. if(GC_on_collection_event) GC_on_collection_event(GC_EVENT_MARK_END); // Событие о конце маркирования. Ну конечно интересует больше другого метод GC_mark_some. В нём фигурирует GC_mark_state — состояние маркировки. Есть несколько основных состояний: MS_NONE, MS_INVALID, MS_PUSH_UNCOLLECTABLE, MS_ROOTS_PUSHED. 1) Изначально вся память находится в состоянии MS_INVALID. Это означает, что область памяти является непомеченной. 2) MS_PUSH_UNCOLLECTABLE. Метод начинает сканировать память смещением по 1 или 4 байта. Находит и отмечает ноды, на которые ссылаются корневые узлы. Scan_ptr продвигается по куче до тех пор, пока все несобираемые объекты не будут запушены, а объекты, доступные из них, не будут помечены. В этот момент следующий вызов GC_mark_some вызывает GC_push_roots для запушивания корней. Это изменяет состояние маркирования на MS_ROOTS_PUSHED. 3) MS_ROOTS_PUSHED. Находясь в этом состоянии, работаем только над опустошением стека меток. Как только стек меток станет пустым, все досягаемые объекты будут отмечены. 4) Когда всё таким образом вглубь просканировано, система маркировки переходит в состояние MS_NONE — все доступные объекты отмечены. С точки зрения кода, вышеупомянутые четыре состояния подразделяются на две основные логики: сканирование корневых узлов и рекурсивное сканирование управляемой кучи. Но рассматривать в рамках постов мы это не будем. Основная процедура выставления меток GC_mark_from вызывается неоднократно на нескольких подфазах, когда стек меток начинает заполняться. Он также вызывается повторно в состоянии MS_ROOTS_PUSHED для очистки стека меток. Процедура предназначена для выполнения только ограниченного количества маркировок при каждом вызове, поэтому ее также может использовать инкрементный тип. Он довольно тщательно настраивается, поскольку обычно занимает большую часть времени на сбор мусора. Всякий раз, когда стек меток переполняется, состояние метки сбрасывается на MS_INVALID. Поскольку в куче зачастую уже есть отмеченные объекты, это в конечном итоге приводит к полному сканированию кучи в поисках указателей, во время которого любые немаркированные объекты, на которые ссылаются отмеченные объекты, снова помещаются в стек меток. Этот процесс повторяется до тех пор, пока фаза маркировки не завершится без переполнения стека. Каждый раз, когда стек переполняется, предпринимается попытка увеличить стек меток. По хорошему — надо сидеть, разбирать по пунктам, чтобы было понятнее. Но не думаю, что это очень нужно юнити разработчику. Как станет лучше — следующие статьи будут выходить почаще. #thematic_post #gc #boehm_gc