Red Hat

As pointed out earlier, why not just keep them around? 8GB is nothing to sneeze at.

Well as a matter of fact my application is already a memory hog... Each RGBA pixel is 4 bytes and the display footprint is barely visible on some of these images. I keep image buffers in memory so the user can 'pan' them using a compressed view to navigate. No problems there because the display footprint is never that much memory and I just discard motion events that occur while the screen is updating. Also redefine the XImage as the new mapping to the display with every update because X was crashing when trying to map an entire 4+ GB buffer. So since its already a memory hog, and can't assume I'm the only app running, just grabbing a massive scratch buffer to have handy seems not a great idea. But maybe I'm missing something about how virtual memory works with that attitude?

But you are using massive scratch buffers, and the memory has to come from somewhere. Give it away and you might have a hard time getting it back.

How about a mid-way compromise? Let the OS decide which bits to cache. Let the OS decide how much memory can be spared against the competition of other programs. Let the OS do all the heavy lifting. You can do this all while still using what's, to your program, still a huge, contiguous chunk of memory.

Make and keep a huge scratch file. You can map that into memory with mmap() -- memory accesses effectively become file accesses. This takes advantage of the file cache, so the OS will cache any bits of it you're using. The OS will cache recently accessed chunks, and turf infrequently accessed chunks back to disk. This is how many large database applications do I/O. If you have enough memory, you'll end up dealing almost exclusively with memory, not waiting for disk.

Your application will have to wait for bits to load, but it will wait for page-sized chunks, not an entire 8-gigabyte memory alloc. And if you have enough memory, it can cache everything without you having to ask. You can also do fun things like "copy-on-write", meaning that the mapping will do just what it says above for reads, but when you write to any of the memory, it won't bother writing the changes to disk, just keep it in RAM.

You can also optimize things further, warning the OS so it doesn't have to guess. "Could you cache these nearby parts for me since the user's probably going to scroll over them soon? More important than whatever faraway parts you have cached, thanks". That's what posix_madvise can do to mmaped segments.