This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GC incremental
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: Re: GC incremental
- From: minyard at acm dot org
- Date: 01 Oct 2001 17:33:57 -0500
- Cc: Jeff Sturm <jsturm at one-point dot com>, Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, "'Antonio Ake '" <ake at ecn dot purdue dot edu>, "'java at gcc dot gnu dot org '" <java at gcc dot gnu dot org>
- References: <40700B4C02ABD5119F000090278766443BEC24@hplex1.hpl.hp.com>
- Reply-To: minyard at acm dot org
"Boehm, Hans" <hans_boehm@hp.com> writes:
> > 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?
Okay, I wasn't thinking here :-).
-Corey