What means "MemoryManager.FallbackAllocation" in Profiler?

Profiler shows a lot of MemoryManager.FallbackAllocations with my bursted path finding job. What do they mean?

 

You allocating native containers inside job I guess

 

Yes, i do this... thanks!

 

this code doesn't use jobs at all, why do I have this?



(it's doing a lot of compute.dispatch though)

@MartinTilo

 

I am pretty sure that that code doesn't use native containers, but I'll double check later.

 

@MartinTilo as you can see from this deep profile, the allocation comes from the internal unity API. You also notice that really would like to save that 1.20ms if it's caused just by it. Should we open a bug or something?



I have also notice that every combine dependency causes one of those



to be honest I feel disappointed that unity eats up precious ms in code that is supposed to be super optimized.

if the solution is a simple as you say (the buffer is not big enough), it would be useful for the user to set up the max size of the buffer. Also the falling back to a slower allocation may need to be optional, as I may prefer actually to be warned about the temp buffer being full.

 

I get MemoryManager.FallbackAllocations when I update systems several times in one frame.

 

Got the info I was looking for, thanks anyway!

 

Can you share your insights?

 

there is nothing special to share, only confirmation that I am not crazy at the moment. I found out that I can set the temp buffer size with Profiler.SetTempAllocatorRequestedSize and that doesn't solve my problem. So there is a bug, but I can't pin it down. I am going to open a bug report.

 

I found a temporary solution to the problem. If anyone has the same problem of appearing several warnings like this in the profiler, read this below.



It started to happen to me, for no reason, from one play to another and it hasn't stopped anymore
All scripts that allocated memory got this warning MemoryManager.FallbackAllocation
The strange thing is that I tested it on 3 different Unity versions and after some time everyone started to do that.
I thought the problem was with a specific script because more errors appeared than the others, but I now found out that it's a problem in the project.


Solution I discovered, just reimport everything. Right click in Project window --> Reimport All



This error will probably come back at some point, but I won't need to create a new project every time to solve the problem.

If anyone knows the final solution please let me know, before the project becomes huge and takes too long to re-import.

I'm using Entities 0.17.0-preview.42 and the problem occurred to me in versions 2020.3.13f1, 2021.1.19f1 and 2021.2.0b9.
It will probably happen in all other versions because I always install a different one and it happens too.


Just one more detail, this message appears in the profiler in EVERY place that allocates memory, not just in the ECS package scripts. Also appears in all messages: "Allocator Name: ALLOC_TEMP_MAIN".

If anyone knows the solution I appreciate it. Sorry for any grammatical errors, I'm using a translator

 

Hi,

Eventually the Unity guys helped me find the root of this problem. The issue starts when native memory leaks are accumulated. Unluckily, in my case, I was using a custom data structure that was not detected by the DOTS memory leaking system, however, even if these data structures were using the tempjob allocations, the symptom was the profiler getting confused and outputting the error we know about.

Once I removed all the leaks, the red lines got away.

To be clear: the memory fallback allocation problem is not due to temp allocations at all and it has nothing to do with it anyway. It's the profiler that somehow breaks when tempjob leaks are accumulated, showing something completely misleading.

 

Just had a similar issue to this. I had just imported the collections package and started testing out jobs.

Noticed that every animator was producing fallback allocations under them (under every animator step). Restarted Unity and everything seems OK now. Will look in to it more thoroughly if it pops up again and post back.

 

it may pop back and if it does is because of memory leaks happening somewhere else (in my case because of me forgetting to free tempjob memory). As I said the profiler is reporting something completely wrong (and indeed impossible as I know that that code is not using temp allocations), Unity should treat this profiler issue as a bug.

 

@MartinTilo this problem has been already debugged by Dale Kim on the Unity slack channel (https://fogbugz.unity3d.com/default.asp?1295061_ubukdcaesdnvt7tn). You can discuss this with him. IMO the profiler is lying because in the following profiled section there is no unity code involved at all and temp allocations cannot happen:

 

@Dale_Kim Btw do I need to free allocation manually by calling Dispose API from the Allocator.Temp allocator just like Allocator.TempJob allocator? From what I know Allocator.Temp will auto dispose itself every frame.

 

@Dale_Kim If simply restarting or reimporting the project solves the problem temporarily, is there any way to get the warnings back quickly and purposefully? something like lowering the necessary leak threshold to trigger these warnings, so you can find the leak location quickly after changing the code and starting the game a few times. In my case, the delay in starting to receive these warnings in Profiler (until the memory doesn't completely accumulate) is what makes it difficult to detect the problem location. I would also like to know if after solving the problem these warnings will automatically go out without having to reimport the project or clear the memory, so that I don't keep searching endlessly for solutions in useless places, something like a button to clear accumulated memory.

 

@Dale_Kim I still don't understand how you can be right. GPUInstancerManager.LateUpdate is a plugin, written purely in c#, that doesn't have any DOTS related code or use native memory. I fail to understand how FallbackAllocation can happen then. Please refer to the screen shot below.



To be clear: you are right about the memory leak problem, but I cannot see how the profiler is NOT lying in the case above. Why is it reporting FallbackAllocation issues on code that doesn't use native memory at all?

The only explanation I have is that some API, like the Graphics class, now uses native memory too.

However, one note I have to add is that

Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak

doesn't happen all the times a leak happens, it stops spamming the console after few frames, which led us to think it was a glitch more than a permanent issue.

By the way, since we fixed our leaks the problem is of course not occurring anymore.

 

Ok I assume when you say lots of calls in to native you mean through the unity API, that's what I expected and it explains it.

Thank you a lot for looking into it and confirming it.

 

sorry I am not sure anymore, you may need to place some blocks to see it happening. However, I am satisfied with the theory that unity native code may use temp allocations. I previously thought it was a DOTS thing only.

 

The reason is:
In Unity, we use stack allocator to allocate memory that would be used in a function or in serveral frames. It's super fast, but the memory size is limited to 128KB~1MB according to different platforms. When you allocate more than 128KB~1MB, Unity would use FallbackAllocator, which is much slower than stack allocator, and you would see MemoryManager.FallbackAllocation in profiler.