Re: GC incremental

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

On 30 Sep 2001 minyard@acm.org wrote:
> > 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.

No doubt about that.  I meant to say it is uncommon in the source code,
not in actual use.  So any potential workaround in libgcj wouldn't be too
intrusive.

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

I was imagining an allocation scheme in which every page would consist
entirely of ptrfree objects, or none at all.  Since each object type has
its own free list, it doesn't seem very difficult.

> And all GCJ objects have pointers, BTW, even arrays.

True.  But the static vtable of a primitive array can be ignored for
marking purposes.  From prim.cc:

# ifdef JV_HASH_SYNCHRONIZATION
  // Since the vtable is always statically allocated,
  // these are completely pointerfree!  Make sure the GC doesn't touch them.
  __JArray *arr =
    (__JArray*) _Jv_AllocPtrFreeObj (size + elsize * count, klass);
  memset((char *)arr + size, 0, elsize * count);
# else


Jeff