[REBOL] How Texans store their persistent objects.
From: chaz::innocent::com at: 19-Oct-2000 14:07
I may not yet understand the issues involved in memory management, but to
this dilettante, any technique promises to solve such issues AND that calls
itself by such a whimsical name - "pointer swizzling at page fault time" -
[PS--PFT] - has got to be a good thing.
That NAME - "pointer swizzling at page fault time" - it makes me want to be
in a dark room, the only illumination coming from an ignored monitor behind
me with a Windows blue screen of death, while before me a beautiful woman
intently swirls a glass swizzle stick into a beverage - half alcoholic/half
virtual - comprised of liquors and memory address locations.
Which has absolutely nothing to do with the following - namely, a
low-overhead method that provides huge address spaces, that can be
implemented across many platforms and OS's, requiring only existing virtual
memory features - but dreams are free.
the original page http://www.cs.utexas.edu/users/oops/papers.html
Paul R. Wilson and Sheetal V. Kakkad. Pointer Swizzling at Page Fault Time:
Efficiently and Compatibly Supporting Huge Address Spaces on Standard
Hardware. In International Workshop on Object Orientation in Operating
Systems, pages 364-377, Paris, France, September 1992.
Pointer swizzling at page fault time is a novel address translation
mechanism that exploits conventional address translation hardware. It can
support huge address spaces efficiently without long hardware addresses;
such large address spaces are attractive for persistent object stores,
distributed shared memories, and shared address space operating systems.
This swizzling scheme can be used to provide data compatibility across
machines with different word sizes, and even to provide binary code
compatibility across machines with different hardware address sizes.
Pointers are translated ("swizzled") from a long format to a shorter
hardware-supported format at page fault time. No extra hardware is
required, and no continual software overhead is incurred by presence checks
or indirection of pointers. This pagewise technique exploits temporal and
spatial locality in much the same way as a normal virtual memory; this
gives it many desirable performance characteristics, especially given the
trend toward larger main memories. It is easy to implement using common
compilers and operating systems.
Vivek Singhal, Sheetal Kakkad, and Paul Wilson. Texas: An Efficient,
Portable Persistent Store. In Persistent Object Systems: Proceedings of the
Fifth International Workshop on Persistent Object Systems, pages 11-33, San
Miniato, Italy, September 1992.
Texas is a persistent storage system for C++, providing high performance
while emphasizing simplicity, modularity and portability. A key component
of the design is the use of pointer swizzling at page fault time, which
exploits existing virtual memory features to implement large address spaces
efficiently on stock hardware, with little or no change to existing
compilers. Long pointers are used to implement an enormous address space,
but are transparently converted to the hardware-supported pointer format
when pages are loaded into virtual memory.
Runtime type descriptors and slightly modified heap allocation routines
support pagewise pointer swizzling by allowing objects and their pointer
fields to be identified within pages. If compiler support for runtime type
identification is not available, a simple preprocessor can be used to
generate type descriptors.
This address translation is largely independent of issues of data caching,
sharing, and checkpointing; it employs operating systems' existing virtual
memories for caching, and a simple and flexible logging system.
Pagewise virtual memory protections are also used to detect writes for
logging purposes, without requiring any changes to compiled code. This may
degrade checkpointing performance for small transactions with poor locality
of writes, but page diffing and sub-page logging promise to keep
performance competitive with finer-grained checkpointing schemes.
Texas presents a simple programming interface; an application creates
persistent object by simply allocating them on the persistent heap. In
addition, the implementation is relatively small, and is easy to
incorporate into existing applications.
the source code for Texas Persistent Store