Does allocating and freeing a huge chunk of memory at startup "clean up memory?"

Question

The book Game Coding Complete, Fourth Edition, chapter 5 (Game Initialization and Shutdown), section Checking Memory contains this interesting code sample:

bool CheckMemory(const DWORDLONG physicalRAMNeeded, const DWORDLONG virtualRAMNeeded)
{
    MEMORYSTATUSEX status; 
    GlobalMemoryStatusEx(&status);
    if (status.ullTotalPhys < physicalRAMNeeded) 
    {
        // you don’t have enough physical memory. Tell the player to go get a 
        // real computer and give this one to his mother. 
        GCC_ERROR("CheckMemory Failure: Not enough physical memory."); 
        return false;
    }
    // Check for enough free memory.
    if (status.ullAvailVirtual < virtualRAMNeeded) 
    {
        // you don’t have enough virtual memory available.
        // Tell the player to shut down the copy of Visual Studio running in the 
        // background, or whatever seems to be sucking the memory dry. 
        GCC_ERROR("CheckMemory Failure: Not enough virtual memory.");
        return false;
    }

    char *buff = GCC_NEW char[virtualRAMNeeded]; 
    if (buff)
    {
        delete[] buff;
    }
    else
    {
        // even though there is enough memory, it isn't available in one
        // block, which can be critical for games that manage their own memory 
        GCC_ERROR("CheckMemory Failure: Not enough contiguous memory."); 
        return false;
    }
}

This raises some questions.

The first part just asks the OS (Windows) how much physical RAM is available. The curious part is the second one, which allocates a huge chunk of memory and frees it right away:

char *buff = GCC_NEW char[virtualRAMNeeded]; 
if (buff)
{
    delete[] buff;
}

The author goes on to explain:

... this function allocates and immediately releases a huge block of memory. This has the effect of making Windows clean up any garbage that has accumulated in the memory manager and double-checks that you can allocate a contiguous block as large as you need. If the call succeeds, you've essentially run the equivalent of a Zamboni machine through your system's memory, getting it ready for your game to hit the ice...

But I have my reservations on that.

"Cleaning garbage that has accumulated in the memory manager?" Really? If the game has just started, shouldn't there be no garbage?

"Making sure you can allocate a contiguous block?" In the very specific case where you are going to manage memory yourself, this would them make some sense, but still, if you do allocate a lot of memory right of the bat, you pretty much make it impossible for any other application to run in the system while yours is on.

Also, isn't this likely to force the OS to commit all that memory, and as consequence evict a lot of memory to the swap disk space, slowing your app startup a lot?

Is this really a good practice?

Answer 1

One thing that pre-allocating a large chunk of memory could do, if your computer was low on RAM, might be to force the OS to free some extra space by swapping parts of other programs' memory space to the disk.

Since such swapping is generally a very slow operation that pretty much freezes your program while it's happening, there could be some advantage to ensuring that, if it's going to happen anyway, it will happen before your game starts rather than in the middle of gameplay.

That said, forcing a swap-to-disk like this is not exactly 100% reliable:

• On many virtual memory implementations, merely allocating memory doesn't actually trigger any swapping; rather, it only happens when you first access each page of the memory you allocated. (This is certainly true on modern versions of Linux, with memory overcommit enabled, as it is by default; I don't know for sure how different versions of Windows handle it.)

  Thus, if you really want this code to "clean up memory", you should probably add a memset() call or equivalent to actually write data to every part of the array (or at least to the first physicalRAMNeeded bytes of it) before releasing it.

• Also, forcing the OS to swap other programs out of the RAM like this doesn't mean that they'll stay out of it. Windows is a multitasking OS, and as soon as one of those swapped-out programs wants to run again and to use its swapped-out data, it will get swapped back in, potentially freezing your game again.

  Thus, this trick is generally only useful if the RAM is being eaten up by large chunks of data that are not being actively accessed (such as large documents left open in the background in some editing software). Web browsers tend to be particularly problematic in this regard, since, even if you're not actually using a web page opened in some background tab, the page may still have scripts running on it that force it to be kept in RAM.

  (There are ways for a program to actually tell the OS to lock a part of its memory space into RAM and prevent it from being swapped out, but these typically require elevated privileges. In any case, the code you posted does not appear to be using any such methods.)

Basically, this trick seems only useful in that relatively narrow borderline situation where the user would have enough RAM to run your game (and any other software actively running in the background) without swapping, but that RAM is currently filled with inactive and unused open files or other data that can and should be swapped to the disk while your game is running. In such situations, it may be effective in making your game seem smoother and more responsive, by replacing occasional small swap operations during gameplay with a single one during startup.

Answer 2

I don't know how old that writeup is, but I'd say it's pretty old. In modern Windows (XP and newer, but specially on 64-bit versions), I would say doing something like that will have little to negative impact on the startup of your game.

First of all, remember that the address space is virtualized for each process. As far as your process is concerned, you have the entire address space to yourself, and you will always get contiguous (virtual) memory, regardless of whether that memory is physically contiguous or not.

In fact, whether or not the memory is contiguous in physical memory is not something you have control over. The OS will choose how to allocate the physical blocks as it sees fit, and nothing you do at the application level can have effect on the benefits (if any) of having contiguous physical memory.

You do need to care about virtual memory fragmentation if you keep on allocating and freeing memory of different sizes for a very long amount of time. This is of course much less relevant with a 64-bit address space. Games don't usually run for months, so you most likely won't have to care about this, unless we're talking about long running game servers.

Even if you do allocate lots of memory of wildly different sizes in a 32-bit machine, modern memory allocations are pretty good, so it is unlikely you will get virtual memory fragmentation issues unless you're actively looking for them

To be honest with you, I don't know what that writer is going on about. Even if the address space was shared, and you did get a huge contiguous block in physical memory, by freeing it, you're saying you don't care about it anymore. There are other programs running on the background doing their own allocations, so even if your huge malloc succeeded, nobody will guarantee the next one will succeed as well.

I think that's a case of "it worked for some reason I don't really understand, so I made something up to explain it".