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: Heap fragmentation (Was: Debugging "Leaks" With Boehm-GC)


NO_DEBUGGING seems to be set by the collector's configure.ac if it thinks
you are building a cross-compiler.  I'm sorry I had forgotten about that.

You will need to build without NO_DEBUGGING, since that also prevents
GC_dump from being defined.

This facility was really meant to be used by either calling GC_dump
occasionally from either client code or the debugger, or setting the
environment variable, and having the collector do so implicitly on a
regular basis.  GC_dump_regularly wasn't really meant to be externally
visible or set, though in fact there is nothing to stop you from just
assigning to it in C code.  If we wanted to add a different mechanism for
setting it, we could add a setter to the GC.

Hans

On Sun, 15 Jan 2006, Martin Egholm Nielsen wrote:

> >> A call to GC_dump() or setting the GC_DUMP_REGULARLY environment
> >> variable should tell you what's in the heap.
> > No, do you recall:
> > http://gcc.gnu.org/ml/java/2005-12/msg00083.html
> > setting GC_DUMP_REGULARLY doesn't affect anything - what should happen?
>
> Oh, I found this:
>
> #   ifndef NO_DEBUGGING
>        if (0 != GETENV("GC_DUMP_REGULARLY")) {
>          GC_dump_regularly = 1;
>        }
> #   endif
>
> So I guess NO_DEBUGGING must be defined in my case... Hence, a bit late
> to do it that way...
>
> Then I should somehow find a way to set "GC_dump_regularly" - but
> there's no nice setter method for that one(?)...
> Any ideas?
> Recompile without NO_DEBUGGING (where is actually the correct place to
> remove this - some Makefile.*?)
>
> // Martin
>
>


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