This is the mail archive of the java@gcc.gnu.org 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]
Other format: [Raw text]

RE: [RFA] boehm-gc for AIX


On Tue, 29 Jan 2002, Boehm, Hans wrote:
> 2) Have a plan for diagnosing missing root registrations, e.g. an
> environment variable setting that asks the collector to register all static
> data segments up to address N as roots.  (This would still require finding
> the main data segment on platforms like AIX.)

I like this approach.  We could enable this option always in a debugging
build (except maybe on losing platforms, since e.g. we don't know how to
do shared libs on most non-ELF targets).

One idea I have in mind is to modify g++ and gcj to emit static
constructors to register roots for any CNI or Java source files.  If this
can be done portably we'll have the info for any possible collector
implementation on any target, and boehm-gc can choose whether or not to
additionally scan all known data segments.

We could also use that technique to skip junk like .eh_frame in the
optimized case.

> I think it would also be nice to have an established way to redirect
> malloc/new in CNI code so that they allocate traced, but not collected,
> memory.  As it stands, I believe there is no easy way to get the collector
> to scan C/C++ objects in CNI?

Can this always be done reliably?  How about using the invocation
interface in which libgcj is loaded at runtime?

My hunch is that one should not count on scanning C/C++ heap
objects, at least for gcj.  (I realize that in some circumstances this is
very useful.  I used it when adapting the boehm gc to gcc, as a
drop-in replacement for ggc-page.)

Jeff


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