Управление памятью в Unreal Engine

Пока не набралось материала для нового двелога по моей маленькой инди-игре, решил описать, как работает Управление памятью в Unreal Engine. Это фундаментальная часть движка, поэтому необходимо хотя бы примерно представлять, как она работает.

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

В UE есть две системы, которые существуют параллельно и дополняют друг друга.

Казалось бы, зачем две системы для работы с указателями? Дело в том, что если мы будем использовать умные указатели с UObject, то можем получить неожиданное поведение. Ведь, удалив его через умный указатель, никто об этом не узнает, и он будет считаться живым.

Умные указатели — это обёртка вокруг обычных указателей, которая считает число ссылок на себя. Для начала разберем какие вообще бывают умные указатели.

Используйте умные указатели для всего, кроме UObject (либо используйте С-стиль, но не удивляйтесь, что нога дырявая 🙂). Они будут сами следить за памятью, которую занимает объект.

Что такое сборщик мусора и зачем он нужен. Если верить Википедии, то

Сборщики мусора избавляют нас от висячих ссылок и утечек памяти.

Как известно, UE работает на C++, который не имеет сборщика мусора. Не проблема, он есть в самом движке. И тут возникает вопрос, как он работает и как не поссориться с ним по незнанию. Ведь ошибки, которые могут появиться из-за неправильной работы с памятью, буквально ломают мозг. Вот один пример из моей практики.

GC, как было сказано выше, работает только с UObject, поэтому нужно их где-то хранить. И такое место есть — GUObjectArray. Это список всех UObject, которые были созданы. Они в нем хранятся в виде структур FUObjectItem.

При создании какого-либо экземпляра класса производного от UObject происходит следующее.

Да, для UObject тоже есть разные ссылки. Называются почти так же, но с добавлением слова «Object». Мы рассмотрим только два основыных из них

Про последние 2 хорошо написано в китайской статье (переведите страницу плагином в браузере и наслаждайтесь) .

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

Сильный указатель хранит в себе напрямую адрес UObject в памяти, при чем гарантирует, что объект не может быть собран GC. Это делается путем перегрузки функции AddReferencedObjects, где сильный указатель добавляет хранимый объект список жестких связей (для определения достижимости объекта, при обходе GC, о чём чуть позже).

Слабый указатель не хранит внутри адрес UObject в памяти напрямую. Взамен этого он хранит его серийный номер и индекс в массиве GUObjectArray. При попытки получить указатель на объект происходит поиск в массиве по индексу и сравнение серийных номеров. Если всё совпадает, выдается указатель (class UObjectBase* Object). Серийные номера не могут совпасть у разных объектов, так как гарантируется, что они не могут уменьшаться. Таким образом гарантируется однозначность слабых указателей.

Простое объяснение состоит в следующем.

При запуске сборки мусора начинается обход всех элементы GUObjectArray по жестким ссылкам (проверяется их достижимость). Те элементы, которые не были пройдены за этот обход, считаются мусором и помечаются для удаления. Обход начинается с элементов корневого набора (Root Set). Корневой набор — это набор объектов, которые не могут быть удалены сборщиком мусора.

Обход можно представить в виде такого графа.

При обходе каждого элемента происходит отсмотр всех его жестких ссылок. Жесткой ссылкой считается

Обычной ссылкой в блупринтах считается следующее.

Кроме того, что CachedCharacter — это уже ссылка из нашего класса на персонажа, так мы еще персонажа ссылаем на наш класс по средствам делегата, который так же считаются жесткой ссылкой.

Если мы хотим удалить эти ссылки, то нужно отвязаться напрямую и обнулить переменную.

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

Если пройтись по этому углубленно, то получится следующее.

После того, как мы нашли все объекты, нужно их удалить.

Purge Thread чистит память для каждого объекта в массиве GUnreachableObjects:

И вот всё чистенько.

Настройки сборщика мусора Project Settings — Engine — Garbage Collection.

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

По умолчанию кластеризация объектов (UObject) включена, так же её можно включить и для всех актеров (AActor). Либо для каждого нужного вам актора делать это вручную (bCanBeInCluster=true или CanBeInCluster() override).
Но есть один минус. Если кластер достаточно большой, то все отдельные элементы в нём будут подготовлены к удалению в одном и том же кадре, что может вызвать спайк.

Также можно выключить/включить многопоточный поиск достижимости GC.

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

Спасибо за прочтение этой статьи! Буду рад вашим дополнениям и уточнениям. Заходите в мой телеграм чатик, буду рад видеть вас там)