[Gc] GC works great, but keeps to itself...
Mon, 17 Nov 2003 12:42:04 -0800
Currently if you use configure, The macro SILENT always ends up defined, and hence
no logging output is generated by default.
If you define the environment variable GC_PRINT_STATS you will see the logging output that
can easily be dynamically generated. (This excludes some statistics which would require
additional overhead in inner loops. That code isn't compiled in, and hence the statistics
GC_quiet is an override that turns off logging messages that would otherwise be
generated. By default, they're not generated.
The combination of REDIRECT_MALLOC and threads is often a bit brittle, but it also
seems to work on my RedHat 8 machine. The problem is that the thread initialization code
may call malloc, which calls GC_malloc, which acquires locks etc., which potentially requires threads
to be at least somewhat initialized. This is on my list of things that could stand
improvement. Use with caution in the meantime ...
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]On
> Behalf Of Alec Orr
> Sent: Monday, November 17, 2003 11:09 AM
> To: firstname.lastname@example.org
> Subject: [Gc] GC works great, but keeps to itself...
> Good afternoon,
> We are using GC version 6.2 for LinuxThreads against a POSIX
> target. I
> haven't been able to fetch any logging messages from GC, threads
> created, intialized, whether it's running, or when garbage
> are taking place. We can see the SIGPWR and SIGXCPU signals
> in gdb. I ran the configure with the following options (all
> on one line):
> In gdb we disable the signals GC uses:
> signal SIGPWR nostop pass print
> signal SIGXCPU nostop pass print
> And we were hoping to see some statistics like the Java GC mechanism.
> We have the GC_quiet = 0; and have reset the GC warning
> handler to our
> own function, which hasn't been called either (GC's seems to
> run without
> a hitch that we can see, so this doesn't suprise me).
> Anything I'm missing?
> Thanks for your time...
> Alec Orr
> WBEM Solutions
> Gc mailing list