We allude to unduplicable caps here but many capability patterns demand duplication. There are no security problems with a machine op that takes a powerful cap c to some block, and annihilates all caps to blocks within. Two variations on this are useful by either:

There is, however, an obvious performance cost to such an op. A system call(?) could put such a block on a list of blocks, caps to which are to be annihilate in an efficient batch process. There are various ways to avoid disk traffic in this process. Keykos never went to disk upon deleting recent pages or nodes, and deleted older material with only one disk operation.

Assuming the pattern: CPU-cache-TLB-DRAM-disk hierarchy where the cache associates virtual addresses, this annihilate operation can be fairly promptly performed by:

Either of these actions leaves the virtual address range unusable; the actions merely have the immediate effect of canceling the outstanding caps to the data that was in the tree of blocks accessed by c. Attempted use of such caps can transparently replace the cap with a null cap which gives the referencer a plain indication that the storage exists no longer. One plan is to let the range lie fallow until a global sweep that annihilates keys thereinto in an efficient batch process. Another plan is to quarantine all cap blocks until they have been, on demand, swept for stale caps. Hardware designed for routing Internet packets based on IP addresses (v4 or v6) seem almost ideally designed for detecting stale keys.