LargeAllocation.Free causes

[wispy haven]

I've got a SearchJob that seems to be generating huge LargeAllocation.Free calls. There's very little info online on what this LargeAllocation.Free is. It may be the Allocator.Temp containers that are created during each iteration of SearchJob.... however, there's another MoveGroundPath job that allocates even more Temp containers but doesn't generate this. So I'm not sure what is causing the red bars in the two images. Also, running SearchJob in parallel causes far more LargeAllocation.Free calls than running it on one thread

It looks like whatever this call is, it "invades" the profiler timeline of other running jobs. ThresholdFailJob for example should not take 2 entire ms, yet the LargeAllocation.Free call seems to be counting as part of its runtime

[wispy haven]

I replaced all Allocator.Temp container creations in SearchJob with just reusing the same Allocator.Persistent container passed into the job, and made the job single threaded. Now the red bar is completely gone.

I’m confused as to how this is the case. Another job allocates even more Temp containers, but doesn’t generate these red bars

[proper sparrow]

🤔 If u use WorldUpdateAllocator, what's the results?

[narrow perch]

Do you know how much memory is being allocated with Temp in your SearchJob?

By default the temp allocator for each job is 256KB, but will allocate a new block of 512KB (and if that exhausts we x2 the size again etc...) if more is requested during the job. When the job frees it frees that memory. The free should not be so expensive but it's possible there is something we can improve there to hide this cost since the free of this memory is pretty unimportant as far as your job is concerned.

If you have a small repro, making a bug with the project would be helpful

[wispy haven]

According to the image of the profiler, the memory allocated is 67 Megabytes, and stays that exact number across multiple frames. The red bar begins the moment SearchJob ends, so it must be SearchJob. This is further correlated by the red bar disappearing after I started passing in a Persistent container instead of allocating new ones

[wispy haven]

Is that the property of a system that I can grab and insert into a job to be used when allocating new containers?

And I want the red bars to stay. They indicate serious memory mismanagement, and are actually causing the performance to degrade

[narrow perch]

The temp allocator is setup so it should be free so you don't need to worry about red bars. They shouldn't exist. It looks like a bug to me in the engine with how temp memory is being allocated.

The WorldUpdateAllocator is a temp allocator with a lifetime of two frames. If your allocations are made in a job, you would need to be certain your jobs finish within two frames for the memory to remain valid.

[proper sparrow]

Btw I tried to new NativeMultiHashMap with WorldUpdateAllocator to use it persistently that keep reusing the same NativeMultiHashMap but it's doesn't seems to have any issue. Will it have any issue? Or it's better to change to Allocator.Persistent?

[narrow perch]

If you are allocating with the WorldUpdateAllocator once, and then not disposing after two frames (at most) then yes you'll run into problems.

The memory will likely remain valid (you won't crash) but on frame 3+ other code using the WorldUpdateAllocator could start giving out memory addresses the WorldUpdateAllocator is using which will lead to memory corruption

If you'd like to keep the map around for longer, use Persistent

[proper sparrow]

🤔 Weird. It just worked without any crash after very long time at actual player runtime build.

[narrow perch]

The memory will likely remain valid (you can read/write to it) but an allocation later could change a value in your hashmap for instance. That could reproduce in what look like logic bugs rather than a crash

That map in particular tends to allocate big blocks of memory which it indexes off of, so it's possible we won't stomp over a ptr (which could lead to a crash the next time we try to use the ptr) but instead it stomps over keys and values which will make it look like the contents of your map are randomly changing

[proper sparrow]

🤔Actually I see a couple of UnsafeUtility.Malloc red bar that one of it takes quite some time at physics that takes around 0.038ms at Android build. I guess the cost is still quite higjt

[wispy haven]

Thank you. I’m concerned that a Temp bug may exist. Do you have any suggestions on which Allocators to use when allocating NativeLists inside of a job?

Each nativelist will reach a size of 1KB max in each IJobEntity iteration