Re: status of gcj's boehm collector?

[Adam Megacz <gcj at lists dot megacz dot com>]

Thanks for being patient with all my questions...


"Boehm, Hans" <hans_boehm@hp.com> writes:
> They're currently coupled in that they both use the same mechanism
> and in that GC_enable_incremental() will turn both on.

Ah, now everything makes much more sense.


> > This seems to be a reason why an incremental collector with page-level
> > granularity would have lower throughput than a generational
> > collector. Am I correct?

> This isn't an incremental versus generational issue.  They both need
> a write barrier, i.e. some way to determine what has been modified.

Really? I'm probably wrong about this, but I thought that a
generational collector simply tagged objects according to when they
were allocated, and scanned recently allocated objects more often,
hence providing better performance for programs that allocate lots of
short lived objects (ie you don't have to scan the potentially large
group of long-lived objects every time).


> Smaller granularity than page size is usually better for the write
> barrier.  But there are tradeoffs.  If the granularity is too small,
> just looking for modified regions can get expensive.  Using the VM
> system as a write-barrier has the significant advantage that you
> don't slow down long-running but non-allocating code.

> Using the VM system as a write-barrier has the significant advantage
> that you don't slow down long-running but non-allocating code.

I'm sure somebody's already thought of this, bug I always figured it
would be neat to have the OS map the top and bottom 2GB of virtual
memory into the same physical space, so that the garbage collector
could flip the top bit of any pointer on and off with impunity.. use
it as a free mark bit. Kinda like the bottom two bits of a pointer,
except if the application dereferences a pointer with marked bottom
bits, a hardware exception usually occurs (accessing nonaligned memory
regions, etc).


> Generational collectors need a write barrier to track writes to old
> objects.

Can't they just do a scan of "new objects" every n milliseconds, and a
full heap scan every n * 10 milliseconds?


> That currently involves catching write faults on Linux.  And those
> write faults can still happen in system calls.

Hrm, so in the failure case, the GC suspects that a page has not been
modified, when in fact it has. Worst case, you get a memory
leak. Could we solve this problem by requiring that the application
periodically call some fullHeapScan() function that performs (big
surprise here:) a full heap scan?

Sure, it's not elegant, but it would appease people running
latency-critical (ie user interface) code.


> 1) Use a software write barrier.  Insert instructions to keep track
>    of heap writes.

Ugh, so every time a pointer value on the heap is modified, a second
memory access has to be performed to update the target page's dirty
bit? That sounds *really* expensive.

  - a