Resumption

In order to continue a computation from a persistent store, the user simply selects it in the application manager. The operating system will then invoke the wrapper code at the beginning of the store which will in turn locate the SpotlessVM and invoke it, passing the store as a parameter. The VM will then perform the following steps in order to resume the suspended computation.

First, it will open the store database and map the store header to the appropriate C struct (see Section 1). The store header is the only record of type 'STOR' in the database and can thus be uniquely located by the VM.

Next, the VM will start opening the individual heap records - these can be identified by their record ID (ranging from 1 to lastRecordId) and type ('VMem'). After opening and locking a record, the header information has to be updated in case the record has been moved since it was suspended. This operation involves three major changes to the record header.

1.

Adjust the ``bump'' state. If the record has been moved from an aligned to an unaligned address or visa versa, its bump state has changed. The new bump state can be obtained from the record's new memory address. The old bump state can be detected by reading the first two bytes of the record's new memory area. If these contain 0xFFFF the record was bumped when the store was suspended. If the old and the new state differ, the record has to be moved by 16 bits to a 32-bit aligned memory address. Note that the required space is always available as the initial allocation requested 16 bits more memory than necessary to hold the heap record (Figure 4).

2.

Adjust header fields. If the record has been moved, all pointers from the header into the heap segment need to be adjusted. The old location of the record can be read from the header field address and be compared to the record's new location.

3.

Append an entry to the break table. We build on an improved version of the SpotlessVM with a compacting garbage collector that uses a break table [Haddon and Waite, 1967] to update pointers to relocated objects. We reuse the garbage collector code to adjust pointers to objects located in heap records that have moved (see 3.3 for more detailed information on the garbage collection algorithm). At this point the VM simply has to append an entry to the global breaktable to reflect the movement of the current record.

After all records have been opened and the appropriate break table entries have been appended, the VM runs a (slightly modified) pointer update phase of the garbage collector in order to adjust the pointers within the heap and from global C variables (still being stored in the store header) into the heap.

After all pointers have been updated, individual modules of the VM are asked to restore their state from the contents of their associated store header field.

Then callbacks that have been registered to recreate external state are executed (see 3.4).

Finally, the virtual machine resumes the execution of the application from the point where it was suspended earlier.