Why this memory management trick works?

Question

Refers to this Unity documentation and go to section

Large heap with slow but infrequent garbage collection

    var tmp = new System.Object[1024];

    // make allocations in smaller blocks to avoid them to be treated in a special way, which is designed for large blocks
    for (int i = 0; i < 1024; i++)
        tmp[i] = new byte[1024];

    // release reference
    tmp = null;

The trick is to pre-allocate some memory chunks at the program start.

Why does this trick work?

Are the chunks being somekind of "registered" (or "bound") to the application when they are being pre-allocated, so that even though the tmp is being freed when Start() is finished, the OS still treat these chunks as "registered" to the application? Since the chunks are "registered" to the application, so the heap size of the application is expanded to certain size, and the next time it acquires memory chunk, the OS would just pick it from the heap of this application.

Is my explanation correct? No matter Yes or No could someone please explain in more details, thanks.

Answer 1

It's not really a trick. It's the way that parts of Unity3D handle memory.

In Unity3D you have objects that are handled by Mono and will be garbage collected, and objects that are handled by Unity, that will not be garbage collected. Strings, ints etc are cleaned up by Mono automatically and we do not have to worry about this. Texture(2D)s etc are not, and we have to dispose of these objects manually.

When a request for memory is made the first thing that happens is that the memory manager scans the application's currently allocated memory from the OS for a chunk large enough to store the data you are requesting. If a match is found, that memory is used. If a match is not found, then the application will request additional memory from the OS in order to store your data. When this data is no longer used up it is garbage collected, but the application still retains that memory. In essence, it sets a flag on the memory to say it is 'usable' or re-allocatable. This reduces the requests for memory made to the OS by never returning it.

What this means is two things;

1) Your application's memory will only continue to grow, and will not return memory to the OS. On mobile devices this is dangerous, as if you use too much memory your application will be terminated.

2) Your application may actually be allocated way more memory than it actually needs. This is due to fragmented memory. You may have 10MB of available memory in your application's memory pool, but non of those chunks are large enough to house the data you need to store. Therefore, it is possible that the application will request more memory from the OS because there is not a single piece of contiguous memory available that can be used.

Because you're creating a large object, an therefore requesting memory, when you set that object to null and signal to the garbage collector that memory is no longer needed by the application, it is quicker to reallocate that kept memory to other objects rather than requesting additional memory from the OS. It is this reason why in theory this particular method is fast and will result in less performance spikes as the garbage collector is invoked less often. Especially as this is a large, contiguous memory allocation.

Answer 2

Why does this trick work?

This trick works because the application won't return memory to the OS, unless the OS memory manager is low and explicitly requests them to do so, in which then they will free up as much as possible. There is an assumption that once the memory is allocated, it will be needed again. If it is already allocated, there is no reason to return it back to the OS, unless it really needs to use it.