[gclist] memory protections and system calls

[Giuliano Carlini]

Hans Boehm wrote:
> 
> I'm not quite sure I understand how this technique works:
> 
> Let's assume we have a page that's written near the beginning of program
> execution, never paged out, and never written again.
> 
> It will always have to look dirty to the OS, just in case it's paged out.  Thus
> when I flush things to disk, the device driver will be requested to write it
> out.  This fails to give me the information which I need, which is usually
> something like:  "Was it written since the last time I asked?"

I don't think so. I've got to learn to take more time when
I write. I keep forgetting to describe important stuff.

The VDB client - say an incremental collector - can tell the
VDB to clear a bit. For example, the collector will do this
just before scanning a page. If the mutator then writes to
the page, the kernel will usually - after some delay - swap
out the page out. The driver intercepts this, sets the dirty
bit, and passes the write on to the "real" driver.

Meanwhile, the collector asks the VDB for a dirty page,
tells the VDB to clear the page's dirty bit, and scans the
page. At times the collector will find that the VDB is
empty. At this point it flushes the psuedo-device file,
which causes the kernel to write every dirty page. The
driver intercepts the writes and sets the dirty bits.

The flush logic is written so that the driver only updates
the VDB's, and does not pass the write on to the real
driver. This leaves the kernel in an inconsistent state.
The kernel believes the pages it wrote aren't dirty. But,
since the driver didn't pass them on, the write never took
place. So, the driver had better tell the kernel that the
page is still dirty. Ideally, the interface between the
kernel and driver supports some way to do this. If not,
the VDB logic can touch every page that the flush logic
marked as dirty.

This keeps going on until the collector calls flush, and
flush marks only a small number of pages dirty . The
collector freezes the world and finishes.

As you can see, this allows the collector to track
"Was it written since the last time I asked?"

For increased efficiency, the collector can register a
handler which the driver executes just before writing the
page. This can be used to ensure that a scan is deferred
as long as is possible. This will work only for pages which
are infrequently accessed. Frequently touched pages will
have to be handled by the above loop.

I've got no idea whether this will work in practice. I've
made many assumptions about the device driver model, how
drivers interact with the kernel and the program in user
space, and who know what else. But, I've looked at it a
bit, and have not found any stoppers yet.

g