We claim that all state is in pages and nodes and is thus swappable and checkpointed.
The node conceptually includes a bit indicating that it has a process in it.
This is a fiction for disk checkpoints.
Upon checkpoint a list of node <a href=Kernel/CDA.html>CDA</a>’s with a process is kept in a separate table which becomes part of the checkpoint.
Between checkpoints the set of processes is just those members of a certain set of queues plus those occupying some CPU.
Domains on these queues cannot be swapped as there is no mechanism to remember that there is a process in them.
Theoretically this can lead to RAM exhaustion that cannot be relieved by swapping.
It has not been a problem in practice.
It can be exploited by a hostile program however—a DOS attack.
<p>A solution that I thought of fairly recently would be to add an architected slot in the meter that serves as a limit on the number of processes below.
It would be an up-down counter just as the CPU slot is a down counter.
It would be cached just as the CPU counter is cached.
Upon exhaustion, fork invocations would fail and the meter keeper invoked.
See “meter” <a href=Reproducible.html>here</a>.
<p>When user code must manipulate crypto keys, especially RSA style keys, timing of the CPU and effects upon the cache provide noise that may reveal key bits to another curious program that is in a position to detect small timing artifacts.
A high level meter manager is in a position to temporarily stop all programs with tools to run non-deterministically.
During such a hiatus key operations can proceed, even concurrently.
Legitimate key code has no need for non-deterministic tools.
Thus no listening code can sense real time to derive timing information.
Note that shared memory between threads can be prevented here.
This impacts design of high level schedulers.

<p>Domains collectively under a meter allowing just one process cannot derive noise thru multiprogramming, and are thus more nearly limited to running reproducibly.
This might solve another problem too; a covert signal receiver might use two real CPUs to time signals.
This limit could limit hostile receivers to just one CPU.
This is queasy as it presumes that you can identify potentially hostile receivers.
<p>In place of an expected clock we might deliver a meter-clock that delivers a pseudo time derived from the time value in the meter.
A systematic substitution of the meter-clock for the ‘real-time clock’ would provide the illusion that only the domains under the clock were running.
If meter timings were weighted instruction counts, a new hardware feature, then these clock readings would be deterministic.