Persistence: a proposal

[David Gadbois]

[Scott, Kelly, and Patrick discuss Smalltalk 80-style object tables.
It is kind of weird to think that all of this stuff, which still seems
so cutting-edge, was originally proposed 20 year ago when I was still
in grade school.  Will the tots of today be raving about parametric
polymorphism in the 2010's?  I don't think so.]

Having object-table handles does make it easier to do things like
read-barriers and object migration.  With all the details hidden
behind the table, it does have a more object-centered feel to it.  And
you don't need forwarding pointers, which always complicate things in
a big way.

But, eek, indirects through memory are a Bad Thing these days.  One
idea I have been toying with is really taking advantage of VM page
protections to do all that.  Divide the address space in two:  The
lower half is the area that is normally used, and the GC sets write
protections on pages in this area for inter-generational pointer
detection, and read protections for incremental forwarding pointers.
The upper have is mapped to the same physical pages, but always has
the protection bits turned off.  The VM fault handler would, if the
page were resident, set the high bit on the address and either (in the
case of a read trap) do a read from the unprotected area for the
forwarding address and restart the read from there, or (in the case of
a write trap) note the violation restart the write.

I gather CMUCL already does something like this.  Could anyone
describe the details?  This scheme would clearly lose bigtime with an
inverted page table scheme.  It also does give up half the address
space, already a precious commodity on 32-bit machines.  Maybe use
separate segments on architectures that support such things?

--David Gadbois