The historical point was that for Spring OS "fast path" calls, if you kept register stack small enough, you could avoid spilling at all. Switching from task A

The historical point was that for Spring OS "fast path" calls, if you kept register stack small enough, you could avoid spilling at all. Switching from task A to task B to service a "fast path" call AFAIK (have no access to code) involved using WIM register to set windows used by task A to be invalid (so their use would trigger a trap), and changing the ASID value - so if task B was already in TLB you'd avoid flushes, or reduce them only to flushing when running out of TLB slots. The "golden" target for fast-path calls was calls that would require as little stack as possible, and for common services they might be even kept hot so they would be already in TLB.