Re: GC incremental

[minyard at acm dot org]

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

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

True.  That's actually how both Boehm's and my GC works, I think.

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

The vtable can't be ignored in the long run if classes are ever
unloaded dynamically, and the sync pointer can't be ignored (unless it
has been moved out of the object, which I think there was some
discussion of, but I haven't checked the new sources).

You could have the array object have a pointer to the actual block of
data instead of the data being allocated as part of the object, that
way the array data would be allocated separately (and could be pointer
free).  It wouldn't be too hard to do that if everything in libgcj
uses the standard array access macros/inlines, which I think is the
case.  It would break binary compatability pretty severly.

-Corey