The C# unmanaged memory layer allows you to access the native memory layer to fine-tune memory allocations, with the convenience of writing C# code.
You can use the Unity.Collections
namespace (including NativeArray
) in the Unity core API, and the data structures in the Unity Collections package to access C# unmanaged memory. If you use Unity’s job system, or Burst, you must use C# unmanaged memory.
Unity’s native code libraries track native memory usage through a system of memory labels, areas, and roots that are managed by Unity’s native memory manager. The ProfilerA window that helps you to optimize your game. It shows how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating, or in your game logic. More info
See in Glossary uses the native memory manager to monitor native memory usage. The asset garbage collector also tracks types that inherit from UnityEngine.Object
so that on calls to Resources.UnloadUnusedAssets
it can clean up memory assigned to assets that are no longer referenced.
Unity’s native memory manager uses memory labels to categorize memory usage and to choose which Allocator
allocates the memory. Which allocator the memory manager uses for each memory label varies between platforms.
The memory manager uses areas to categorize memory usage for profiling purposes. It uses roots to track related memory allocations under one root. For example, the native memory for each type that inherits from UnityEngine.Object
has a root in the area called Object
. When the object is deleted, for example via Resources.UnloadUnusedAssets
, all allocations associated with that object’s root are also freed.
You can use the Memory Profiler package to see memory usage ordered by memory labels, areas, and roots. You can also see which underlying allocator allocated the memory through region names.
You can use certain native Allocator types with native container types in the Unity.Collections
namespace. The allocator types available in this way are:
Temp
: A temporary allocator type for short-lived allocations.TempJob
: A temporary allocator type for longer-lived allocations passed from job to job.Persistent
: An allocator without any temporal restrictions.AudioKernel
: An allocator for DSP audio kernel allocations.Domain
: An allocator that lasts the lifetime of the domain.To use these types, pass an Allocator
enum value to select the native allocator type’s memory label to use. If a chosen Temp
allocator is full, Unity chooses a fallback allocator instead (usually TempJob
, or Temp Overflow).
Temp
is Unity’s temporary allocator type. It’s designed for small short lived allocations that can’t cross a frame boundary, such as temporary allocations made within a single job. The Temp
type is a stack type allocator for small amounts of memory which Unity allocates from the main memory pool.
There are multiple Temp
allocators, and each thread that needs an allocator has one. Unity recycles Temp
allocators each frame ensuring a clean memory usage pattern. However, if memory spills over into the fallback allocators, their memory might get fragmented.
You can use Profiler.GetTempAllocatorSize
and Profiler.SetTempAllocatorRequestedSize
to get and set the size for Temp
allocators.
The sizes for the Temp
allocator default to:
If these sizes are exceeded, allocations on the main thread fall back to the TempJob
allocator, and on other threads they fall back to the Temp Overflow allocator. For more information on temporary native allocations, refer to the Thread storage local (TLS) allocator documentation.
This type uses a linear style allocator which Unity stores in a TempJob
area that it allocates from main memory. It’s designed for larger temporary allocations that are passed from job to job, and those that might carry data between frames. If the allocations aren’t disposed of within 4 frames of their creation, a warning is displayed in the Unity Editor.
Note: If the memory available is exhausted, Unity makes the overspill allocations in main memory (malloc). Most platforms can have up to 64 MB of TempJob
memory, but on smaller memory systems this limit can be as low as 16 MB.
If this allocator is full, allocations fall back to the Temp Job Overflow Allocator. For more information on temporary job allocations, refer to the Thread safe linear allocator documentation.
This allocator allocates memory with no time restrictions, is only limited by the amount of free memory on a device, and therefore has no fallback. It can exist for as long as you need it, but this also means that only the DisposeSentinel
class warns you if you don’t free the allocated memory again, and then only if your handle to the memory was garbage collected. Allocating persistent memory is slower than allocating temporary memory.
Did you find this page useful? Please give it a rating:
Thanks for rating this page!
What kind of problem would you like to report?
Thanks for letting us know! This page has been marked for review based on your feedback.
If you have time, you can provide more information to help us fix the problem faster.
Provide more information
You've told us this page needs code samples. If you'd like to help us further, you could provide a code sample, or tell us about what kind of code sample you'd like to see:
You've told us there are code samples on this page which don't work. If you know how to fix it, or have something better we could use instead, please let us know:
You've told us there is information missing from this page. Please tell us more about what's missing:
You've told us there is incorrect information on this page. If you know what we should change to make it correct, please tell us:
You've told us this page has unclear or confusing information. Please tell us more about what you found unclear or confusing, or let us know how we could make it clearer:
You've told us there is a spelling or grammar error on this page. Please tell us what's wrong:
You've told us this page has a problem. Please tell us more about what's wrong:
Thank you for helping to make the Unity documentation better!
Your feedback has been submitted as a ticket for our documentation team to review.
We are not able to reply to every ticket submitted.