Re: GC incremental

[Jeff Sturm <jsturm at one-point dot com>]

On Sun, 30 Sep 2001, Bryce McKinlay wrote:
> The GC_begin_syscall() aquires the global allocation lock, effectivly 
> making all IO single-threaded.

Eww.  That's not good.

> Also why is the wrapping neccessary anyway? Is it just that kernal 
> writes to the heap dont get noticed by the GC, or is it more serious 
> than that?

As I understand it, kernel writes to read-only memory cannot occur, i.e.
a read() to a heap address may fail with errno == EFAULT.

But that should be rare in libgcj, where most system calls act on
stack addresses.  One exception is java::io::FileDescriptor::read which
writes directly to a byte array.  A byte array is pointer free, so it
really doesn't need to be write protected.  I don't know if the GC
makes this distinction however... it looks as though GC_protect_heap
protects everything.

One alternative to the syscall wrappers is modifying FileDescriptor.read
to pass a stack address and copy the buffer.  It's hard to say if that
would be any better or worse than serializing I/O.

BTW I experimented with PROC_VDB and libgcj a little on Solaris.  The
results were inconclusive: there were no obvious benefits from
incremental GC in run time or heap size, but the tests were likely skewed
by some other anomalies I'm still planning to track down.

Jeff