Store Structure

Although we eliminate the distinction between primary and secondary memory for objects, we borrow the notion of a ``store'' from persistent object caching systems to describe the entire durable memory image of an application. A Spotless store captures the execution state of a running program, its heap, and additional boot information necessary to resume the virtual machine at the point where it was interrupted.

Such a persistent store is represented by a PalmOS resource database of the type 'appl'. This type tag causes the application manager to display the store like any other application installed on the Palm. Figure 1 illustrates the basic structural components of a store:

Figure 1: Store Structure

1.

The wrapper, which contains a minimal boot program (less than 1 KB in size) that simply locates the Spotless VM program on the device and then starts it, passing the user-indicated store as a parameter.

2.

The store header, which contains all global C variables that cannot be re-established from the context. These are mostly the various roots of the system, that is, references to objects located in the segmented heap. It also contains pointers to the first and the last of the resource database records that represent the store contents. The store header itself is stored in a resource record of type 'STOR'.

Figure 2 shows the definition of the associated C structure. The field externalManager will be explained in more detail in 3.4.

Figure 2: C Data Structure Representing the Store Header

3.

The segmented persistent heap. This is the area where objects are placed by the allocator and moved or deleted by the garbage collector. Each segment is stored in a resource database record of type 'VMem' and is 64KB in size (the largest contiguous area that can be allocated in any Palm database).

Each record has its own header block containing status information for the segment. Figure 3 shows the definition of the C structure that contains the header data.

Figure 3: C Data Structure Representing a Heap Record

The segmented heap is represented by a linked list of records using the next pointer to locate the following one.

The VM requires all heap objects to be located at a 32-bit aligned address, whereas the operating system may return addresses that are only 16-bit aligned. This problem is solved by actually requesting 16 bits more than needed to hold the record, which leads to one of the following situations.

If the memory area returned by the OS is not 32-bit aligned, the record is ``bumped'' up to the next 32-bit aligned address. When an application is suspended, the fact that the record was bumped is indicated by setting its header's bumped field to TRUE and the two bytes before the record to 0xFFFF (Figure 4). This will be recognized by the VM when it resumes the application, and then it can properly align the contents of the record as described further in section 3.2.

If the memory area returned by the OS is 32-bit aligned, the record is simply placed at the beginning of that memory area leaving 16 bits at the end of it unused.

Figure 4: Bumping of Unaligned Addresses