Allocating "weak" memory pages

Question

I am interested to know if there is a way to allocate "weak" memory in userspace in common operating systems like Linux, OS X, or Windows (obviously not possible with standard interfaces). What I mean is the sort of an mmap(), which would invalidate the mapping if the OS elects to push the pages out of core.

Say, I want to work with a 10G dataset on a 32-bit system. To get a piece from this dataset, I read it from the file and decompress it to memory[. I would prefer to keep the decompressed versions of the pieces around, if possible, to avoid decompressing the data on each access, but to allow accessing all pieces I must eventually free some data to avoid exhausting the memory/address space.

I can emulate this by gluing a framework on top of malloc() to free the old pieces if malloc() NULLs out, but it deprives other processes of memory and makes them to page out (or pages out the decompressed pieces). Or, I could keep some soft limit in the application, but that seems arbitrary and only alleviates the problem, and is suboptimal if there's free memory around. I feel that this is something that a virtual memory manager in a modern OS should handle.

Any tips and information about how this problem is tackled in other modern applications are appreciated.

Answer 1

No, there is no mechanism in common operating systems that implement the weak userspace memory as you describe.

Weak references come from the domain of garbage collection frameworks where an object/allocation is otherwise abandoned (i.e. has no "strong" references). The weak references will be invalidated/nulled if the garbage collector gets to the allocation before the application attempts to recycle it by assigning the weak reference to a "strong" one.

The functionality you describe in your question and in the subsequent comments could be better and more simply implemented by an application cache that discards "pages" when he cache fills up and overwrites them with newly needed "pages". Be careful to implement mutexes if the cache can be accessed by multiple threads. The mutexes (if needed) are the most exotic thing here. Everything else is pretty standard vanilla programming.

By way of an academic exercise, you could implement the concept you are describing at the kernel level with a device driver meaning the capability would be exposed as a pseudo device. I would be very reluctant to acutally base a production implementation on this pseudo device as it has a negative effect on portability and maintainability, could adversely affect the entire platform's performance and behavior (after all we're talking kernel code here), and would by comparison take a long time to develop and test.

Good luck in your endeavor.