Question What on earth is "Reserved" memory and why is killing me?

Hi @hypnoslave !

"Reserved" highlights the memory that was allocated from the operating system for Unity's native memory management system.

Unity memory management uses pooling system for native allocations. We allocate a relatively large sequence of pages of 4-32MB in total size and then serve smaller allocations for different subsystems (e.g. Unity objects).
The "reserved" part itself is the difference between total pool size and what is actually used by Unity's native memory manager.

We are planning to add more insights in the All of Memory view to the Reserved node in the next Memory Profiler release, however we do also have reservations as this may be not really actionable and hidden by default. (There could be a possibility of using https://docs.unity3d.com/Manual/memory-allocator-customization.html to play with the "reserved" overhead, although it is a game of memory vs performance overhead).

Hope that clarifies what reserved part means.

 

Yes, it is possible - this problem is known as "memory fragmentation". The allocation and deallocation pattern may result in larger blocks being underutilized and ever growing. It is relevant to both native and managed memory managers.
Although it maybe relatively hard to crash on platforms where memory is paged, but it will definitely impact performance to some extent.

 

It's not just fragmentation. If you take a snapshot while you're in game for the first time it probably shows most of that as used. If it reuses most of the space when you go back for a second time after going to the menu, fragmentation isn't your issue either. It is that the in game scene pushed your high water mark up and Unity's allocators are generally greedy because asking for memory is costly, so they will keep the memory reserved, assuming it will likely be reused.

It can also be that the high water mark is reached at the point of loading a scene, as the memory used for assets used in the previous scene is not unloaded as that scene is unloaded but only on the next unload after that, in case it would be reused in the next scene. Loading an empty scene in-between or calling Resources.UnloadUnusedAssets is a possible way to trade of longer loading times for lower high water marks of memory usage.

 

@NameString yes, resident vs allocated memory is another topic related to the question of Reserved memory in so far as that the reserve memory doesn't necessarily have to be resident. In the 1.1.0-exp.1 version of the Memory Profiler we've added the ability to analyze that difference more granularly, and we just released a blog post that goes into more detail on the topic.

That blog post also provides some tips about analyzing Reserved memory, like

 

Whoops, looks like I pasted the link in there twice and thereby broke it. I've corrected it in the post itself.

But also, since then, we released version 1.1.0-pre.1. For details on the latest version, you can always check the pinned threads in the Profiler Previews subforum and we do try our best to remember to update this thread as close to the release date as possible, so you can switch on "Watch this thread" for notifications of new version releases.

Do note that the blog post mentioned above still has a mistake in it in claiming that the more granular per object breakdown of allocated vs resident would be available for captures taken of 2022.2+ versions, that is only available for captures from 2023.1+ versions.

 

It depends. Managed memory may be returned to the OS once a page (usually about 4kb) has been entirely empty for a while (every 6th GC.Collect in the current implementation of the Mono and IL2CPP Boehm GC as of writing. This is an implementation detail that you shouldn't bank on. Also, calling GC.Collect multiple times until you hit that

GC_CollectsSinceStartup % 6 == 0

is not helpful and should be avoided. That is, because it will fragment longer contiguous virtual address space that could have been reused even further.)

Native memory may, depending on the Allocator, also be unloaded but that may be even less predictable to the point where you might as well assume it won't happen.

That said, different platforms deal with stale memory differently. Such unused memory may end up getting pushed out of Resident memory by getting compressed, moved to swap file/ just unmapped from physical memory until needed again.

You can go into the Memory Profiler preferences and check the option to see detailed breakdowns for reserved memory. With 2023.1+ and package version 1.1 you can also get per page granularity residency information displayed that may help you identify what of that you actually need to care about, i.e. allocated but non-resident unused reserved memory won't get your app evicted by the OS.