Re: GCJ and Boehm GC "Incremental Collection"

[Hans Boehm <Hans dot Boehm at hp dot com>]

It's a page fault for something like the first write to each page per GC
cycle, which tends to be MUCH cheaper.  My impression is that on Linux
this is probably often competitive with the compiler write barriers used
by most commercial JVMs for generational GC.  In some cases it can be much
cheaper.

The main down sides of this approach are:

1) It usually fails for writes which are made by system calls rather than
store instructions.  Hence you need to avoid generating SIGSEGVs for
those.

2) The granularity is too coarse.  You'd like to have more precise
information about what was written than just the page.

For C/C++ clients I usually don't have a choice.  For gcj, it may make
sense have the compiler insert a write barrier, at least in some cases.

Hans

On Tue, 6 Dec 2005, Andrew Haley wrote:

> Hans Boehm writes:
>  >
>  > The difficulty comes with tracking updates during marking.  We
>  > normally do that by relying on the virtual memory system, often by
>  > protecting oages and then catching faults.
>
> A page fault for every heap write?
>
> Andrew.
>