This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: gc problem?
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: gc problem?
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Wed, 24 Oct 2001 18:44:27 -0400 (EDT)
- cc: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, "'Anthony Green'" <green at redhat dot com>, "Java at Gcc dot Gnu. Org" <java at gcc dot gnu dot org>
On Wed, 24 Oct 2001, Boehm, Hans wrote:
> Aren't there also other issues with the debug information for the stack?
Most likely. I don't think DWARF2 debug info would be of much help.
The unwind info is more interesting... it must be accurate in the presence
of optimizations, else EH would fail. Even though it uses the DWARF2
format, it is a GCC extension, so presumably it could be extended and
adapted for other runtime uses.
> This is only loosely related to the questions the garbage collector
> might ask: "Can the value in register Rn possibly be dereferenced at some
> point in the future?" The answer to the last question might be "yes" even
> if Rn doesn't hold the value of any program variable.
The unwind info describes where registers are saved in the call frame, but
unfortunately doesn't indicate precisely if or when a register is in use.
It also doesn't say anything about stack slots other than a return
address, saved frame pointer, or other caller-saved registers.
As an experiment, I modified the fuction prologues on SPARC to initialize
all locals to zero in a large program. That ought to cut down
misidentification from the stack. There does seem to be measurably fewer
blacklisted blocks as a result, although overall run time and heap size
didn't change but a few percent. So I'd be inclined to disable the
warnings and ignore it.
Jeff