Supporting both Intel 8088/8086 and 80x86 CPUs

[Brendan]

Hi,

Having a global system for freeing "freeable" RAM is a good idea; but it needs to cover everything (not just file caches, but all caches/buffers used for any purpose, discardable data used to improve search performance, any garbage collected RAM), and also needs to interact with things like swap space and memory mapped files and the "out-of-memory" killer. For example, if a process has allocated a lot of RAM that is only used very rarely, then you probably want to send the process' data to swap space so that you can use the RAM to cache file data that is accessed often. For real mode you can't really do most of it (no memory mapped files, no swap space, no allocation on demand, no copy on write, etc), so in that case it devolves down to just freeing stuff.

You can most certainly implement swapping in real mode. As a result, you can also most certainly implement memory mapping. The implementation is going to be completely different from it would be on a system designed purely for virtual memory architecture, but it is entirely possible.

The method is simple: Rather than allocating memory directly, you allocate a memory handle. The application then locks either the whole handle, or a region of that memory handle to get its address. When the application has finished working with the memory object, it unlocks the region. You can extend this to memory mapping of files. You can also take advantage of this scheme to move memory around and reduce fragmentation

Macintosh System 1 did this on a 68000. I'm sure the Lisa did as well. 16-bit Windows did it too; you can see the legacy of this in the Win32 Local* and Global* APIs, which are a part of Win32 just to simplify porting Win16 applications.

I'm also sure that you could create some system involving thunks in order to support paging of code segments as well. It would be crazy, but it would be workable

That would work.

I was trying to think of something that doesn't require any special support in user space (e.g. processes just do their own thing without caring how virtual memory is implemented), and couldn't think of any way to have something like "not present" segments (where the exception handler fetches data from disk).


Cheers,

Brendan

[Owen]

When dealing with limited hardware, it is often essential to think "what is the effect I want to achieve, and how can I implement it within my constraints?"

In this case, the effect is "swapping". There is no hardware support, so we have to implement it in software.

From this, I would then think "Is there any feature in bigger systems that has parallels to this? Is this feature useful at all in bigger systems?", and to that, I would say yes and yes. Because, really, we are talking about a special case of memory mapped files here. So, make your memory handle a pseudo-file handle, and merge it with the file mapping APIs. And we have designed a generally useful feature here, because we have created anonymous shared memory that can be passed around by DuplicateHandle, Local sockets, or whatever your equivalent is.

(You can also extrapolate another useful feature from this: A way for 32-bit apps on a 64-bit or PAE OS to access more memory than its address space contains. In a way, as things grow, we just repeat patterns on a larger scale.)