This is the mail archive of the java-discuss@sources.redhat.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]