gcj executable size reduction?

[Boehm, Hans]

The only negative consequences I was referring to was the necessity for
explicitly registering static roots.  It's unclear to me whether this matters,
and particularly the extent to which you can hide it with smart pointers
without making those expensive.  It probably is an issue if the CNI code
is really just an interface to C code.

I think this plan still makes sense, but as I've argued before, I'd like to
leave a conservative scan of static data as an option.  I think it's easy to make
it a run-time option.

I was hoping that someone knew an easy way to get a hold of particularly
the exception range tables, in which case we could not only get a partial
short-term fix for gcj, but also solve a GC problem for a bunch of other
clients.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Tom Tromey
> Sent: Thursday, April 15, 2004 10:27 AM
> To: Boehm, Hans
> Cc: 'Per Bothner'; java@gcc.gnu.org
> Subject: Re: gcj executable size reduction?
> 
> 
> >>>>> "Hans" == Boehm, Hans <hans.boehm@hp.com> writes:
> 
> Hans> If gcj supplied precise root information to the collector, this
> Hans> would no longer matter for gcj.  But that hasn't happened yet,
> Hans> and has some negative consequences.
> 
> Hmm, what are those?  My recollection of "the plan" is that when we
> made the next major changes to CNI (e.g. the smart pointer stuff) we
> would also change things to require root registration.
> 
> If the bookkeeping for this is excessive or something, let's change
> plans.  That won't hurt since we haven't done anything yet :-).
> 
> I thought we had a PR for this but I can't find it.  Let's figure out
> what we want and then put it in bugzilla, perhaps as a dependency on
> the new ABI tracking PR (12725).
> 
> Tom
>