Nope. Logical copying (as well as copy on write) is fully supported.

It order to read data from a file, a task sends a read request to the appropriate filesystem server. The filesystem checks its cache to see if the data is already in memory. If it is, it asks the physical memory server to make a logical copy of it and place it in a client supplied "container". If the data is not in core, the filesystem sends a request to the backing store driver (e.g. a hard disk) and requests that the data be read in. The filesystem, before returning the memory to the client, keeps a reference to the frame in its cache so that future read requests for the same data will be filled from the filesystem cache.

The design document (in the hurd cvs repository) goes into more detail about the actual mechanisms available to support logical copying and copy on write. But rest assured, this issued were considered from the start and the mechanisms fit nicely into the framework we have developped.

We assume that the max amount of physical memory available to a task will be relatively stable over time. So, usually it will get negotiated at startup time, and then remain constant.

Eventually, the system may get under memory pressure and need to claim memory back. Then the tasks are notified about this and the amount of max memory is renegotiated and memory is claimed back. The exact mechanisms for this are not set in stone yet, there is a variety of options, ranging from simple notification systems to market-driven economic models (which may provide an incentive for tasks to stay below their maximum of guaranteed memory).

I don't think the mechanisms are too important here. What is important is that the consequences will be correct, and the right guarantees are made (this is not easy! If you contact a task to claim back memory, how long should you wait for a reply? We have no idea. Maybe we need support from the scheduler etc). So, we can not give a complete answer to your question at this time. But remember that we already are under memory pressure, and are probably trashing on swap and whatever. So, we already are very inefficient, and thus I don't think performance is the highest concern at this point.

Nothing would prevent a task from doing its own swapping, say to a local, private, swap file, which could also be encrypted (!).

However, to make system-wide sharing of memory possible, even among non-cooperating tasks, the system needs to be involved when memory is swapped out. Otherwise, shared copies would become non-shared when swapping takes place (the task could still share the page with a group of cooperating other tasks, by implementing its own memory protocol!).

So, the task will have to indicate to the physical memory server that a memory page should be swapped out to the system's backing store. This can not be left to the user for all sorts of considerations, including security.

So, to answer your question: Yes and no. If you do it yourself, you will not be able to take advantage of some of the advantages, like transparent sharing. But if you have secret data that you don't want to send to system swap, then you don't want to share the page. In that case, you could use an encrypted private swap file. It's this type of flexibility and user freedom that was one of the main goals of our design.

I should also add that you don't need to swap some memory at all if you want (as long as you don't exceed your physical memory allocation). So, mlock() will actually be available to all tasks of all users, and not require special privileges. It will be implemented as a local call that informs the local pager that a certain page should not be swapped out, ever.

Speed may not be the prime mover, however, that doesn't mean that we design our algorithms to be slow. Far from it. Our first concern is security followed by flexibility and performance.

We believe that you can design unsecure systems that are very fast. But, frankly, we don't think those are very interesting as because they are insecure they have limited appeal.