Memory Management Success + FAILS

[Baker]

[frag.machine]

Hmm, just a wild guess but... Could this memory being allocated by the libc and not your code actually ?

[mh]

The memory usage reported in task manager is more than just that you allocate yourself in your program. It includes allocations made by your drivers, other DLLs that the process loads, etc etc etc. Windows itself might even pre-emptively allocate some memory in case you need to use it sometime soon (so that it's available fast without needing to stall the program while it goes hunting for a free block big enough).

Just to complicate things further - in most cases this won't be actually allocated "real" memory. On a 32-bit PC you can address up to 4GB of memory, right? Now, even if you only have 16 MB in your machine, Windows can actually still address the full 4GB. This - not your swapfile - is what's really meant by "virtual memory". A page table is used internally to map these virtual addresses (which are the ones you see in your program) to real memory addresses.

This 4 GB of potential space is split in two. 2 GB of it (it may be 3 GB on some machines depending on boot.ini/whatever settings) are addressable by your process, and 2 GB by the system (that's not the way it really is but it will suffice for this discussion). Every memory allocation call you make comes from that 2 GB region (that's why you sometimes see pointers with crazy high addresses even on low memory machines). That 2 GB is per-process; each process has it's own 2 GB region to play in. That's (one of the reasons) why you could see big 32-bit servers with more than 4 GB of memory back in the old days - each process could get a different 2 GB region of real physical memory. The other 2 GB is shared by all processes, but that's OK because a process generally can't access it directly (I suspect that on Win9x it was quite easy to circumvent this and cause all kinds of fun to happen).

Ready to go in at the deep end?

On Windows, VirtualAlloc is king, queen and knave of memory allocation. Every memory allocation you make in your program goes through it. malloc goes through HeapAlloc and HeapAlloc goes through VirtualAlloc. Now, the way VirtualAlloc works is that it has this concept of "reserved memory" and "committed memory".

Reserved memory is just a block of address space (not physical memory) marked off; it's obtained by calling VirtualAlloc with the reserve flag. It's a way of saying "this is my block of address space, there are many others like it but this one is mine". Windows promises not to make any other memory allocations from that block unless you call VirtualAlloc again specifying a range in that block and with the commit flag. It's actually kinda like Quake's hunk in a way, in that it's a range of memory that you can draw down from as required. Very very neat API.

It's important to note that reserved memory is NOT NOT NOT physically in use. No matter how much you reserve, your available physical memory will NOT NOT NOT go down (internal bookkeeping structs may knock a few bytes off it). Each process has the full 2 GB to play with. You can reserve 2 GB in one process and if you never commit any of it, you'll still be able to reserve 2 GB in another and you'll still have all of your free physical memory.

(Aside: I more than half suspect that many Weenix Loonies look at the reserved counters and go into paroxysms of joy about how "oh noes, Windoze is teh bloatware!")

Committed memory is regions of that reserved space that are currenly mapped to physical memory. That's the stuff that's actually in use. It gets a little more complex with page sizes and whatnot, but there's the view from a few miles up.

That's why you sometimes see advice about which task manager counters are the ones that really mean stuff. Unless you're looking at the commit size you're getting a false view, and that commit size may include many things that you don't allocate yourself (as well as stuff in the system's 2 GB region, which - because it's shared between processes - may even be the same chunk of physical memory used by many different processes, like a device driver for inst. Think of it as being like multiple entities using the same model. If 300 entities each use a 10k model you don't have 3000k used - you've only got 10k used. If you query the memory used by each entity individually, and if that query includes the model size, you may be seriously misled).

What kind of things? Textures for starters. Sure textures go into video RAM, but each is also backed up by a system memory copy. In ye olde dayes this didn't happen on consumer hardware and doing anything that caused your video mode to be reset trashed the contents of your video RAM. No system memory backup - textures get lost (or replaced by random garbage). That's why GLQuake went nuts when you tried to change the mode without destroying and recreating your context.

The moral of the story is - don't stress too much about task manager counters. Much of what you see there is totally outside of your control. Keep an eye on your own allocations, make sure that you do nothing stupid and let the OS and your drivers look after themselves. It'll be different on different people's machines anyway so not only is there nothing you can do about it, but it's utterly pointless to even try.

Why does DirectQ's memory usage go down? Because my memory manager is so damn awesome? In one sense, yeah. Most everything is dynamically allocated into one of three different types of memory pool (and there may be multiple concurrent instances of each type) and what's not needed doesn't get used. D3D9 obviously works different to OpenGL, so there may be stuff going on there too. Likewise in your driver.

[revelator]

on win7 dwm.exe is notorious for blowing the top of memory allocations if the program in use has even the slightest leak
i had some success using mss to showel most leaks out of code but damn its a bitch.
switching to xp takes quite a load of of the memory so its indeed OS specific as well.

[Spike]

further to what mh stated, you can select different memory displays in task manager. one is 'paged memory' or some such, which is the amount of physical memory which is actually used for that process and will not include unused memory like zero-filled bss sections.

quake's memory usage comes from multiple places. textures, malloc, bss, and some engines use virtualalloc. glquake never destroyed any textures (quake2 does, but not quake), but glDeleteTextures can free up that memory if you wish to use it. free() will tend not to release memory back to the system as its often not page aligned and system calls are expensive in malloc/free intensive code. bss cannot be freed other than by closing the library/program, but it also won't be paged in unless you actually poke it, so you can have a large bss (quake does this a lot) without paying any real penalties other than in coding style. virtualfree is the only way to guarantee that memory is released back to the system, the virtual memory subsystem also a nice way to zero-fill large blocks of memory quickly.
malloc may or may not page the memory in. On linux, malloc does _not_ allocate memory - it allocates address space which is only paged in when its needed. Typically this memory is identical to bss in functionality, except that more address space can be made available for it as needed. The heap provided by virtualalloc for malloc in windows is likely to be the same.

If your system runs low on memory, its quite likely that sections of your exe will be flushed to disk, as they can easily be reloaded without touching the page file. Also its quite likely that the exe wasn't actually fully loaded from disk in the first place, which is how .exe installers with large data payloads can function on a machine with only 8mb ram.
So yeah, the memory usage is a lie.

[Baker]

[mh]

It's worth noting as well that many of the characteristics of Quake's memory management system stem from the fact that it had to run on a Pentium 60 with 8 MB of RAM. Unless you're explicitly targetting that kind of machine, much of what makes it complex can actually go away.

[Baker]

[Spike]

the current heap memory sucks. there's no way to get notifications when stuff gets purged, leading to leaked vbos, glsl, textures, etc.
cache memory sucks for the same reason.

malloc and free are 'easy' in a sense. all that is malloced must be freed. No uncertainty over who owns it, hopefully.

[mh]

On Windows, the Heap- functions rock.

You can create as many heaps as you want - one for permanent data, one for per-game, one for per-map, etc.

One call to HeapDestroy will release all memory in a heap. No need to track and free individual allocations.

HeapCompact will look after memory fragmentation for you.

There are HeapLock and HeapUnlock functions for thread synchronization.

You can retrieve info about a Heap, enumerate all of it's allocations, validate it or get it's total size any time you want.

You would still need to track other objects associated with heap allocations (like wot Spike said) but otherwise the functions are totally awesome.

[Spike]

I meant the quake hunk memory, sorry.

[mh]