Summary of what was learned at Unity Roadshow 2026

Memory Prerequisites

Basic Content

• We use Virtual Memory (VM) and do not directly control physical memory.

• VM is composed of pages, which may vary depending on the OS.

• Windows / Linux 4kb

• iOS, MacOS, Android 16kb

• A physical memory frame exists corresponding to the page.

• Virtual memory is merged into physical memory depending on the level of memory pressure.

Page Fault

A Page Fault occurs when a page that has not been loaded into physical memory is needed.

• Clean Page: A page whose original data has not changed; it can be released by the OS at any time and is easy to reclaim.

• Dirty Page: A page containing information newly written or modified by an application; it cannot be immediately removed from memory.

Memory Footprint

An indicator representing actual memory pressure, resulting from the sum of the total dirty page sizes.

Memory Footprint != Physical memory usage, Resident memory usage

Memory Management (Windows vs Linux)

• Reserved: Does not use physical memory Allocate only virtual memory without reserving

• Commit: Allocates physical frames equivalent to the actual virtual memory

• Decommit: Releases physical frames while maintaining reserved space

Windows: Provides explicit APIs (virtual alloc, virtual free)

UNIX Like: No explicit separation between reservation and commit

• mmap calls implicitly reserve memory

• Lazy commit occurs when accessing pages immediately

• No explicit API; decommit operates via hints

• The OS decides when to reclaim pages

Handling in Unity GC

Managed Heap

• All C# memory allocation takes place here

• Managed by the Garbage Collector

• Indicated as GC.Alloc in Unity Profiler

Garbage Collector

• Periodically collects objects from the Heap that do not have valid references

• Performing GC does not reduce total virtual memory usage

• The space occupied by collected objects is also considered Dirty by the OS

Segment

Defined as a collection of consecutive pages

• Managed Heap uses Segments instead of Raw Pages

• Multiple objects can be allocated to a single Segment

• After allocating and releasing them, there are internally unused instances, but they are marked as RAM usage (because they are dirty)

• In most cases, there are no issues and they are reused soon

• Cases where they remain empty for too long waste resident memory, so Unity GC handles them intermittently

What Unity GC Does

• Uses remapping strategies

• After multiple GC runs, Old Empty Segments are dropped, and New Segments of the same size are allocated

• Windows Remap Strategy: Decommits without releasing Segments (because it is an explicit process)

• UNIX-Like Remap Strategy: Remaps via munmap & mmap (High cache hit rate due to Hot Page effect)

• This has the advantage of reducing resident memory

GC.Collect Should Not Be Run Multiple Times Reasons

• Do not force segment releases

• Collect is expensive and can cause app freezing

• The intention itself is to decommit segments that have been empty for a long time

• Decommitting segments that are briefly empty is contrary to the intention

• Forced decommitting does not improve performance and only incurs CPU costs

• Causes a situation where segments that will be reused in the next frame are also decommitted

VM usage in Managed Heap only increases and never decreases

• The Heap only increases and never decreases

• The inherent characteristics of Boehm GC

• There is no reason to trim virtual memory allocations

• Large virtual memory != Large physical memory usage

• Segments are reused anyway

• Game objects are frequently created and destroyed every frame

• Shrinking segments every time an object is destroyed only wastes CPU performance

Unity Boehm GC

• Unity's Incremental Boehm GC is a Conservative GC

• This supports the task of converting C# code written in the past into C++ It came to be primarily used with the provision of IL2CPP.

• While IL2CPP enabled support for various environments, it appears that the open-source GC Boehm GC was used because, unlike C#, memory GC was not automated.

• Focusing on stability rather than performance, it considers all values that look "like" pointers as references.

• Object locations are not changed during GC -> No compaction, and vulnerable to memory fragmentation.

About Compaction

• Memory compression is advantageous for resolving memory fragmentation. It clears out all unused space to rearrange it.

• Impossible in conservative GCs because accurate reference information is required.

• Moving object locations incurs a cost (Stop The World + actual movement).

CoreCLR GC

CoreCLR GC is a Precise GC that accurately knows which values in the memory stack and registers are references.

And .NET uses CoreCLR as its core engine (CLR: Common Language Runtime)

Features supported by CoreCLR

• CoreCLR GC

• JIT Compiler

• Exception Control

• misc...

This CoreCLR GC (hereinafter .NET GC) uses a generation-based memory management method

• Manages the Heap by dividing it into 3 generations

• Generation 0: Primarily consists of newly created objects; frequent and fast GC occurs (most objects die here)

• Generation 1: Acts as a buffer for objects that survived Generation 0 to move to

• Generation 2: Resides for heavy objects that have survived for a long time; cleaning this area is costly for the GC

• LOH: Very large objects are placed in this space

Fragmentation can be reduced as memory compaction is handled during the promotion process

In the case of LOH, compaction was not performed in the past because the STW (Stop-the-World) lengthens, but it is said that it is now handled as an explicit option.

The Value of the Transition?

Basically, Unity to .NET I mentioned that the change in GC is a side effect of the transition, not the primary one. However, if we look for its value...

• Memory fragmentation is reduced because Compation is supported.

• GC costs can be made predictable.