13.25.3 System continuation objects

Vicare is written in both the C language and the Scheme language; the runtime system performing heap and stack memory allocation and garbage collection is written in the C language. Vicare starts with C code and enters Scheme code when running a Scheme program:

C code --> Scheme code

when the last Scheme function returns: Vicare knowns that it has to return to C code because the Scheme stack is initialised with a return address to a special routine (the underflow handler) that does it.

It is clear that, while running a Scheme program, every now and then Vicare must switch between portions of code written in C and portions of code written in Scheme; such portions make different use of the CPU.

Whenever Vicare leaves C code execution to enter Scheme code execution: it saves the current state of the C stack; in practice it saves the pointer to the top of the stack in the PCB structure. Whenever Vicare leaves Scheme code execution to return to C code execution: it saves the current state of the Scheme stack in the PCB and restores the state of the C stack from the PCB.

While running Scheme code we can call a C function through the primitive, low–level operation foreign-call (when using the FFI callout mechanism we are still using foreign-call):

C code --> Scheme code (--> foreign-call) --> C code

when leaving Scheme code: the status of the Scheme stack is saved in the PCB; the C stack creates no problems: we just retrieve the top of the C stack from the PCB and use the stack region below it, objects continuations system.

    --------- stack growing direction ------->

 C stack   C stack  C stack   C stack    C stack
 frame     frame    frame     frame      frame
|---------|--------|--------|----------|----------|
                            ^                     ^
                       saved top            current top

|...........................|.....................|
   C stack before entering     C stack after
   Scheme code                 reentering C code

Now let’s say that, after entering nested C code, we enter nested Scheme code:

C code 1 --> Scheme code 1 --> C code 2 --> Scheme code 2

at the transition from C code 2 to Scheme code 2 we must save the state of the C stack, but the dedicated fields in the PCB are already busy with the status of C code 1. Vicare solves this problem with continuation objects; at the transition from C code 2 to Scheme code 2:

1. A Scheme continuation object is created to hold the status of Scheme code 1 previously saved in the PCB.
2. A system continuation object is created to hold the status of C code 1 previously saved in the PCB.
3. The status of C code 2 is saved in the PCB.
4. Execution of Scheme code 2 is entered in a clean Scheme stack segment.

whenever Scheme code 2 goes back to C code 2:

1. The Scheme stack segment used by Scheme code 2 is abandoned.
2. The status of C code 2 is restored from the system continuation object.
3. The execution enters C code 2.
4. The status of Scheme code 1 is restored from the Scheme continuation object.
5. The execution enters Scheme code 1.

In a system continuation object:

• The field top is an untagged memory pointer referencing the C language stack last saved upon exiting C code and entering Scheme code; it is the content of the field pcb->system_stack at the time this system continuation object was created.
• The field size of a system continuation object is unused.

Upon creation, both Scheme and system continuation objects are prepended to the linked list referenced by the field next_k of the PCB structure.