[Gc] Collection frequency
clyde at progress.com
Thu May 13 14:42:34 PDT 2004
Thankyou, the GC_free_space_divisor does work as advertised.
It doesn't really solve my problem. It is a static control where I need
a dynamic control.
Ideally, for a typical job on a typical machine, there may be plenty of
memory and I don't want the collector to run at all. I only want to run
the collector if, on a particular day, on a particular machine, the user
happens to use more than, say, 50% of available memory. In that event,
I want the collector to run to keep the usage under control. Is there a
way for the collector to dynamically sense when memory is getting tight,
and then run?
In my original question, I didn't mean to imply that we were actually
experiencing unbounded heap growth. We simply want to minimize the
overhead for the users who don't need it, and dynamically sense when the
user does need it.
- clyde kessel
> -----Original Message-----
> From: Hans Boehm [mailto:Hans.Boehm at hp.com]
> Sent: Friday, May 07, 2004 11:45 AM
> To: Clyde Kessel
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Collection frequency
> The best way to reduce heap size is generally to increase
> GC_free_space_divisor, e.g. to 8 or 10.
> But in either case, you shouldn't be seeing unbounded heap growth.
> If your heap is much larger than twice the live object size,
> you probably have a very small heap, a very large root set, or a bug.
> Note that with win32 graphics applications, there appears to
> be an occasional problem with the GC accidentally tracing the
> graphics buffer. There are partial workarounds for that in
> very recent versions of the collector. It can have the
> symptoms you describe.
On Thu, 6 May 2004, Clyde Kessel wrote:
> We are adding the garbage collector to a product built with C++ on
> The product allocates scads of small objects and your garbage
> collector seems to gather them up quite nicely, thankyou.
> This question relates to choosing the correct frequency to run the
> non-incremental collections. Currently, in order to minimize
> overhead, the collector runs less frequently as the heap grows. That
> may minimize overhead, but it seems to miss the point. As the heap
> grows, the risk of over committing real memory increases, and the need
> for collections increases. I even worry about an instability in the
> current system, as the heap grows, collections diminish, causing the
> heap to grow faster.....
> Is there a way to change or tune the algorithms to get a behavior
> which takes into account these problems (and keeps overhead small :-)?
> - clyde
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc