is based on the Texas
persistent store described by Wilson et.al., there are several
(1) Texas mapped persistent addresses more-or-less directly into the persistent file, and used a separate roll-forward log file instead of being layered on top of a log-structured store.
(2) Texas pages on disk were direct images of the in-memory pages (among other things, limiting the virtual address space to 4GB if you wanted persistable pointers to be the same size as regular pointers. I seem to recall that persistable pointers had an extra field, though... [Check the paper]) The RScheme store serializes pages, affording an opportunity for a larger persistent address space at no cost to in-memory representation size. (As it happens, it also allows us to do persistent page table mapping lookups more efficiently, because for us we only have to do one lookup per referenced persistent page; in Texas it was a lookup per pointer).
(3) In Texas, objects that were to be persistent had to be allocated initially in the store. That's too much of a pain for dynamic systems (e.g., think about all those cons cells you want to persist that were created by calling `append' or whatever). Hence, RScheme automatically migrates (copies) objects into the store when needed.
(4) Since Texas is built for C++, a whole separate technology for RTTD is required. Our store is for a dynamic language, so we leverage the dynamic type information that's already available [include note about gvecs vs bvecs when opening a store without pivots, i.e., from another application]
(5) Since RScheme pointers are always to the "front" of objects, it is much easier to find the header of an object, and it's first allocated page, given a pointer. Because we only allocate multiple pages for "large" objects, and then only put one object in such a multi-page sequence, we can be sure that the "first" page is the page to which the pointer directly refers. This makes it easier to find metadata like what store an object belongs to, once we know that it is a persistent object (future versions of RScheme should allocate transient objects within pages, too, unifying this concept with the transient store).