These features are generally useful, and independent of the type of application. Examination in the context of a specific application category, high performance on-line transaction processing (OLTP), provides motivation for many of the KeyKOS features which support high performance:
KeyKOS provides persistent virtual storage, which assures the consistency of all data periodically via efficient checkpoint, and which has the performance characteristics of virtual memory systems.
KeyKOS provides optional journaling, which assures correctness. It is possible in KeyKOS to make an objective cost/benefit trade-off of providing correctness, in addition to consistency, to retain those transactions which might otherwise be lost as a result of system outage. [An example: If one assumes that the potential data lost during a year has a value of $100, and represents no liability, then almost certainly one would not utilize journaling (whose total cost in implementation, maintenance, computer utilization, etc., would almost certainly exceed $100 in value). In other situations correctness will have a much higher value, and journaling should be employed.]
When the working set of an OLTP application fits in main memory (gigabyte main memories have been delivered commercially, and many working sets are smaller than a gigabyte), the effect of KeyKOS's persistent virtual memory and journaling is to significantly reduce the disk I/O requirements, as compared to conventional systems, and yield extremely high disk efficiency.
One result of this approach is, indeed, the short instruction paths needed for frequently executed transactions. Path lengths of 15,000 to 35,000 instructions per transaction are typical for high performance OLTP systems. [Consider a 10 MIPS (millions of instructions per second) computer. These path lengths would yield maximum transaction rates of 670 and 285 transactions per second (tps), respectively, based solely on CPU capacity.]
To achieve these impressively short instruction path lengths, conventional OLTP systems give up a great deal: security, partitioning (compartmentalization), optional use of hierarchical support architectures for infrequently executed transactions, programming in restricted-privilege compartments to promote reliability and reduce development costs.
KeyKOS cannot and does not change the basic instruction cycle of a computer, nor the efficiency of the code generated by language processors. If it is not possible to program a transaction in some higher level language so as to yield the short instruction paths required for frequent transactions, then assembly language code may be the only alternative. KeyKOS provides this option. KeyKOS gives the option of allowing direct reference and access to underlying mechanisms when required, but allows use of (less efficient, but more productive) hierarchical software architectures for infrequent transactions. KeyKOS is not a layered system, although it allows the construction of layered (hierarchical) support facilities.
KeyKOS provides contexts whose privilege can be restricted as required for the case at hand.
KeyKOS provides an efficient change of context, with no runtime check for access authority required (as conventional systems - based on access list technologies - invariably do if they attempt to provide security).
Thus, KeyKOS allows the coding of the short instruction paths required for frequently executed transactions, but simultaneously provides optional layered support for other transactions (or background batch processes accessing the same data), choice of coding language, choice of programming environment, and security.
Other features which support performance include the ability to share code among many instances of an object, more compact application code due to the centralization of checkpoint/restart facilities, etc. The following is a brief list (with some amplifying comments) of KeyKOS features which promote high performance:
A KeyKOS key invocation results in a context change when a domain sends a message to another domain. Since the KeyKOS architecture is on the level of a computer's instruction architecture, the ability to implement all or part of the kernel in microcode offers the opportunity for increased performance in the future.
Any holder of a key may invoke the key, with security assured. No runtime checks need be made to verify that the holder is authorized to employ the key.
The non-layered system architecture of KeyKOS allows direct access to underlying functions when short instruction paths are required, but does not inhibit the development of layered (hierarchical) support systems for less frequently performed transactions.
It has been argued by some that object oriented programming reduces the size of applications by up to an order of magnitude, as compared with conventional programming technologies. In Key Logic's experience, object oriented programming results in compact functionality. Since individual objects in KeyKOS consume little memory, since objects of the same class share the same code efficiently, and since the code is compact, significant reductions of the program working set appear possible within KeyKOS as compared with conventional systems.
When multiple copies of data are stored on disk, then read performance improves, since it is possible to select a copy of the data which is available for reading. Telephone directory information systems employ eight copies of directory information to improve read performance for this "retrieval only" OLTP system. KeyKOS can provide this (or higher) level of data replication, transparently to the application code.
KeyKOS can write data to disk during a checkpoint at near the theoretical maximum head transfer rate. After a checkpoint, if a change is made to data in main memory, then there is no need to move that data to its home position on disk (operations which need not be performed offer the ultimate in performance).
Correctness can be assured in KeyKOS at the cost of one disk I/O per several transactions.