This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GC incremental


Jeff Sturm <jsturm@one-point.com> writes:

> 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.

It's not rare enough to ignore, and for a blocking read, it will occur
and be very bad.  And locking can only occur for a minimum of page, so
even if your data doesn't have any pointers, some data beside it
might.  And all GCJ objects have pointers, BTW, even arrays.

> 
> 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.

If you have a huge read, you can't do this (unless you can guarantee a
huge available stack space).

In my GC, I solved the problem by waiting for the file with select(),
then locking the memory writable in the GC and performing the read.
That way, you don't block any other threads (except for the GC if it
needs to scan those pages).  It also makes it easier to interrupt the
thread with a signal, since select() will always return on a signal
call.  Of course, you have to handle that properly, but that's pretty
easy.

-Corey


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]