This note is prompted by a phone call from Jonathan Shapiro. Many of the ideas here are his, some of the details are mine.
Sometimes application code loses interest in the state of some large block of its address space. The routine “free”, the companion to malloc, comes to mind. It would be elegant, strategic and sometimes necessary to release the physical storage that holds this state. Such application code may not have convenient access to the segment keeper holding those pages. At least such access would require a number of conventions. Perhaps we should invent a virtual “processor instruction” that zeros a block of memory specified by their virtual addresses, just as normal instructions identify such memory. Of course this “instruction” is interpreted by the kernel. The kernel memory tree logic is in a position to signal the same keeper that would be signaled upon a segment error. A new class of signal to segment keepers is thus called for. This suggests a bit in segmode keys the would prevent such signals. I think that is unneeded. Such actions by a domain requires write access to the segment, of course. The call must respect the no-call bits in intervening segmode keys. I think a bit in the domain accessible via the domain key, should condition this act.
The above paragraph was written sometime in the year 2000, I think. It is early 2002 now and I think now that however the malloc code came to know which virtual addresses were suitable for allocation, it could likewise acquire access to the appropriate segment keeper key. If malloc is modified sufficiently to issue the magic new instruction suggested above, it could at the same time be further modified to be aware of the keeper of that space.
Normal action by the segment keeper will free both RAM and backing disk store.
Some processors have ways of expressing disinterest in memory state so as to free cache sooner than LRU. Security and other considerations require that we specify that these actions produce zeros before the state is accessed once more.
The 360 had an op code “ZAP” whose main use was to zero memory. The spelling of the mnemonic code followed a rigid pattern. I have never been sure whether this was: