The intent of this note is to tell enough about the Keykos space bank to understand some remaining design issues, without digging into the detailed specs for the 370 Keykos banks in the Gnosis manual.

Space banks (just “banks” here) are objects that supply new pages and nodes and accept used pages and nodes for recycling. They are the conventional and almost exclusive way for Keykos programs to manage system space outside their own virtual memory. Banks are organized into a tree and each bank may impose a limit on the net space that it and inferior banks will allocate. The owner of a bank can thus subdivide and delegate his space authority into like pieces of various sizes.

Banks are implemented by domain code and are somewhat analogous to the primitive meters which provide hierarchical allocation by the kernel of CPU time. If you are curious, banks are able to do their thing by wielding the closely held range keys but that is not relevant to this note.

Banks were among the first objects to be designed in Keykos and the space bank transformer is now considered a blunder, but not seriously so. It would have been better to order a new sub bank from an existing bank. The C version does this.

There are different ways of talking about bank operations. We will speak here of buying and selling space from or to a bank. We say “buy a page” where the manual speaks of creating a page, and “sell a page” where the manual says “destroy a page”. It must be understood that buying a page actually allocates a frame from a fixed pool of blocks on the disk system. To sell a page frees the frame and deletes all keys to that frame and page. We say that you get the only key to a page that you buy. This is a guarantee by the bank that is in a position to violate that guarantee.

The original conception of the bank was that an item (page or node) may be sold only to the bank where it was bought. This rule was not enforced and a few programs came to depend on this. The C version enforces the rule.

Space Limits

Each bank has two limits, one for pages and the other for nodes. Each time an item is bought, the limit in that bank and each superior bank is decremented. If one of these limits is already 0 the item cannot be bought and the buy order is rejected. When an item is sold the limits are incremented. This provides hierarchical limitation of space and also allows over-allocation, as in meters. Unlike meters, bank limits move in both directions.

There are facets on the bank to allow reading the limits thus serving as a sort of service key to the bank analogous to meter service keys. The 370 version could not set the limit but this was a harmless oversight since B’s limit could be increased by buying space from the bank immediately superior to B and selling it to B.

Over-allocation is supported in that the limits of the banks immediately inferior to bank B could sum to a value greater than the limit of B.

Another bank operation was to readMinLim (read the minimum of the limits) of the superior banks. Each of the bank keys to the superior banks had to be facets that allowed this operation. Said another way, this order was valid on facet B if that facet had read min lim enabled, and B had been created by invoking its superior via a facet with that order valid. This was included for it was equivalent of buying space until there was no more and then selling it all back.