This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: [RFA] boehm-gc for AIX
- From: Jeff Sturm <jsturm at one-point dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: "'Bryce McKinlay'" <bryce at waitaki dot otago dot ac dot nz>, Tom Tromey <tromey at redhat dot com>, David Edelsohn <dje at watson dot ibm dot com>, java at gcc dot gnu dot org
- Date: Thu, 31 Jan 2002 00:50:24 -0500 (EST)
- Subject: 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