This is the mail archive of the
mailing list for the Java project.
RE: cannot build libjava/gnu/gcj/xlib/natClip.cc
- To: "'Per Bothner'" <per at bothner dot com>, java-discuss at sources dot redhat dot com
- Subject: RE: cannot build libjava/gnu/gcj/xlib/natClip.cc
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Wed, 3 Jan 2001 16:32:35 -0800
> From: Per Bothner [mailto:email@example.com]
> Tom Tromey <firstname.lastname@example.org> 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
> > 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.