[Gc] Collection frequency
hans.boehm at hp.com
Thu May 13 16:13:17 PDT 2004
The problem is that it's hard to shrink the heap when the user starts
the second big application. That's why the collector doesn't have a lot
of support for this kind of thing. The collectors heuristics are
designed to roughly keep GC overhead per byte allocated constant,
independent of the live data size.
If you think it's OK to reserve a large part of the machine,
a semi reasonable strategy might be to call
GC_expand_hp(Half of available memory) when you start, and then set
GC_free_space_divisor to a higher value. A better approach might be to
put a call-back into GC_should_collect() and have it return 0 if
there is enough physical memory that it's safe to expand the heap.
I have no objection to putting such a callback into the official
distribution, but I'd rather leave the policy decisions up to the client.
(This also leaves the problem of how to determine available physical
memory up to the client. Although a bit painful, that's probably also
right, since there's usually no one right answer. E.g. on many systems
you'll end up potentially sacrificing file system buffer cache.
Whether or not you want to do that is probably application dependent.)
There's a lot of discussion of this kind of tuning in the OOPSLA 2001 paper
by Brecht et al.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Clyde Kessel
> Sent: Thursday, May 13, 2004 2:43 PM
> To: gc at napali.hpl.hp.com
> Subject: RE: [Gc] Collection frequency
> 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.
> > Hans
> On Thu, 6 May 2004, Clyde Kessel wrote:
> > We are adding the garbage collector to a product built with C++ on
> > WIN32.
> > 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
> > https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc