cannot build libjava/gnu/gcj/xlib/natClip.cc

Wed Jan 3 16:32:00 GMT 2001

> From: Per Bothner [ mailto:per@bothner.com ]
> Tom Tromey <tromey@redhat.com> writes:
>> > There's definitely an overhead. I have a paper here describing work
> > people (Rick Hudson, I think) did to make gcc emit tables so that
> > precise, copying GC can work. For some applications this 
> overhead is
> > attractive, though, I think.
>> I think the main reason you might want a precise GC (besides concern
> about mis-identified pointers) is to implement a copying generational
> GC. Then you could also have a per-thread nursery, and avoid the
> overhead of locking the heap each time you need to allocate an object.
> I gather this can be a big deal, especially if you do 
> multi-processing.
>> > Anyway, it is unlikely to happen since it is a lot of work.
>> At least not anythime soon.

Per-thread allocation arenas are likely to happen very soon, I hope.
They're in the 6.0 alpha versions of the collector. They are physically
separate only in a weak statistical sense, which may preserve some cache
line sharing problems on a multiprocessor. But per-allocation locking
disappears. (Currently this has only been ported to Linux/X86&IA64, but
that shouldn't be hard to fix.) All of this is pretty much independent of
whether you have a copied young generation.
A copied (i.e. contiguous) young generation probably helps in most cases, in
that you get less pollution of the remembered set by new objects, and you
can allocate a bit faster. You could even do that without precise pointer
information, by using a mostly copying collector for the young generation.
I went partly down that path, and I still have the code. But I lost my
conviction that it would make enough of a difference to be worth the pain.
Based on experiments with C versus Java code, I suspect the length of the
allocation path currently makes more of a difference.
Hans