GC incremental

Mon Oct 1 09:10:00 GMT 2001

> From: minyard@acm.org [ mailto:minyard@acm.org ]
>> Jeff Sturm <jsturm@one-point.com> writes:
>> > 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).
Why would you dynamically allocate the vtable for a primitive array, e.g. an
array of int?
In 3.1, with hash synchronization enabled, there are no sync pointers in
objects. The synchronization data is either allocated statically in a hash
table (the common case), or it's allocated dynamically and referenced from
that hash table. This wins in the expected case for several reasons, two of
them being that the GC no longer has to look at pointerfree objects, and
that the objects are one word smaller. The performance is probably less
predictable, and you may thus want to turn it off if that's a major concern.
Hans