There are many kinds of value that the kernel avoids calculating until the last moment, where the process cannot proceed without the value. Things happen and very often postponed work is avoided work. Two terms are current for this strategy: ‘Lazy evaluation’ and ‘Just in Time (JIT) evaluation’. To a degree the strategy comes from the hardware’s tendency to delay work until needed such as when a TLB entry is not loaded until needed. In that case there is another reason: there is a hardware limit on the number of loaded TLB entries. This is not a religious issue, the IBM 370 model 158 TLB would load a pair of TLB entries for consecutive virtual addresses when either was needed because loading two was as cheap as one and the other entry was fairly likely to be soon needed.

The kernel computes mapping table entries (from which TLB entries are loaded) only upon need. The cost of computing them is often avoided and even the cost of reading a node from disk may be avoided. This is the pattern of demand paging extended to the mapping structures. In this case work is postponed by initializing new mapping tables with patterns that the hardware defines as invalid. The hardware invokes the kernel when it encounters an invalid map entry.

The mother of all lazy computer strategies is demand paging which was first done in the English Ferranti computer in about 1957. It saves RAM (then core) and sometimes, even the cost of computing what is in the page.

This describes how to avoid loading some special control registers every time the kernel dispatches a process, just because some processes need them. In this case hardware features were necessary and foreseen.

Another instance is where we load some large machine state, that most processes do not require, only when it is actually needed. This was not done on the 370 kernel. See this which describes other historic sources.

A more general pattern is adaptive data structures such as adapted meters, prepared keys and prepared nodes.

These patterns were so common in the 370 kernel that we built the IF-THEN macros so that the true branch was out-of-line. Most prospective values that were needed were needed several times. Each time some simple test would determine if they had been computed, (usually they had), but if not the infrequent expensive branch would be taken to the code that would compute the value.