[Gc] Error in simple GC test
hans.boehm at hp.com
Mon Apr 23 10:44:49 PDT 2007
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Christophe Meessen
> Sent: Monday, April 23, 2007 5:35 AM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Error in simple GC test
> Hello, and thanks for answering.
> Andrew Haley a écrit :
> > If you can't
> > tolerate even a few objects not reclaimed you'll have to
> use a precise
> > collector.
And defining precisely what that means may be nontrivial.
> Is there a way to know the amount of allocated gc managed
> memory so I can eventually detect if things get too bad and
> take some brute force cleaning measures like restarting the process ?
For version 6.8 and earlier, you have to build without -DSILENT to find out how much memory the collector thinks is reachable. For 7.0alpha, just setting the GC_PRINT_STATS environment variable should do the trick. (That also will give you some information for 6.8, but probably not what you want.)
> I have seen that work is in progress to integrate a gc in C++
> for the next standard revision tagged C++0X, where X may be
> in hexadecimal ;-).
> Is it intended to be a precise collector ?
There are provisions to allow the collector to use type information. I would expect that initial implementations will do so to a limited extent. Even if we could define what a "fully precise" collector is, it would run into trouble with C-style unions, if nothing else.
The standard can't really impose formal requirements in this area, since it doesn't say anything about space usage of your program. A C++03 implementations that simply ignores operator delete calls is currently conforming, since it is explicitly unspecified if and when the memory is reused. (In most contexts, this would be considered a poor quality implementation, however.)
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc