cni-changes documented?

Boehm, Hans hans.boehm@hp.com
Sat Mar 20 08:39:00 GMT 2004


I'm not sure that handles would help, for two reasons:

1) Even with the indirection, there are still points during program execution,
say in the middle of a field access, where registers contain raw pointers.
Hence you still need to address that problem if you want to move objects.
The major advantage of handles seems to be that they make it easier to do
sliding compaction.

2) On most benchmarks, I would expect the indirection overhead to swamp any
improvement in allocation/gc cost, at least for the kinds of costs I'm seeing.
(There is some evidence that others are seeing higher costs, either because
thread-local allocation doesn't work on their platform, or because it's
mistakenly configured out, i.e. THREAD_LOCAL_ALLOC is not defined.
Anthony Green and I are trying to understand the latter problem.  I suspect
it would be far easier to port thread-local allocation to e.g. win32,
than to add handles.)

In general, I think there are lower hanging fruit (direct calls to the
GC library, more precise static root identification) than adding a copying
young generation, at least if your goal is expected performance.

If you are seeing lots of time spent inside the GC on a hyperthreaded P4,
you might also try enabling (Linux) or porting (Windows) the parallel mark code.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Adam Megacz
> Sent: Thursday, March 18, 2004 10:11 PM
> To: java@gcc.gnu.org
> Subject: Re: cni-changes documented?
> 
> 
> 
> Andrew Haley <aph@redhat.com> writes:
> > I think so.  I exepct the only issue will be ABIs that pass single
> > member structs in a different way from scalars.
> 
> How hard would it be to change GCC's internal representation of a
> pointer to a pointer-to-a-pointer (handle)?  Could this be done as a
> thin layer over the backend (ie a "filter" over the code generator)?
> 
> Obviously this would carry a heavy performance penalty, but it would
> be a quick-and-easy way to get precise GC with a copying collector in
> the eden generation.  It would probably also be a great "midway point"
> towards adding such functionality to Hans' collector in the general
> (non-handle) case.  All the algorithms could be tested in an
> environment where there is no ambiguity about what/where to scan; once
> that code is stable and tested, more complex scanning can be attempted
> without having to worry about the correctness of the compacting
> algorithms.
> 
>   - a
> 



More information about the Java mailing list