Re: [Gc] RE: Abuse of collector...
ivmai at mail.ru
Thu May 7 00:55:42 PDT 2009
"Boehm, Hans" <hans.boehm at hp.com> wrote:
> > -----Original Message-----
> > From: gc-bounces at napali.hpl.hp.com
> > [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Talbot, George
> > Sent: Wednesday, May 06, 2009 12:59 PM
> > To: gc at linux.hpl.hp.com
> > Subject: [Gc] Abuse of collector...
> > Hi all,
> > I've integrated the collector into my program and it works
> > ...
> > Questions:
> > 1) Does the time spent sound sane with experience that
> > others have had?
> If this is a modern X86 box or the like, it sounds too high to me. I would have expected under a second. What's the OS? Can you profile the executable? If not, random interruptions in a debugger might give you an idea. If the time is not being spent in GC_mark_from(), something fishy is going on. Looking at the log output might also be informative. You don't have GC assertions enabled, right?
And You build the collector with -O2 -mtune=native -DNO_DEBUGGING -DLARGE_CONFIG, don't You?
My approx. average timings of a parser app that operates tree-like data (500MiB heap, 2x2.4GHz CPU):
- 260 MiB of ptr-containing data per 1280 ms (single threaded collector),
- 280 MiB of ptr-containing data per 70 ms !!! (single threaded, GC_ENABLE_INCREMENTAL),
- 260 MiB of ptr-containing data per 800 ms (2 marker threads),
- 270 MiB of ptr-containing data per 240 ms (2 marker threads, GC_ENABLE_INCREMENTAL).
> > 2) Is there a way to spend less time in the allocator during
> > the initial startup?
> Explicitly calling GC_expand_hp() with the approximate final heap size should help.
> > 3) Am I reasonable to believe that in the parallel
> > collector, generational features will save me from super-long
> > collections if my data structure is relatively constant after
> > the startup? (i.e. no more than say 5% changes every couple
> > of hours or so.)
> Incremental collection currently doesn't combine well with parallel collection. And incremental collection is somewhat tricky to use anyway, depending on the platform. It's not on by default.
> Turning on only generational collection with parallel GC may be OK. To do that, set GC_time_limit to GC_TIME_UNLIMITED, and then call GC_enable_incremental().
Simply call GC_enable_incremental() after (or instead of) GC_INIT() (GC_time_limit is set ss needed by the collector itself) or set GC_ENABLE_INCREMENTAL environment var. Anyway, check whether it shortens the gc delays (in average) for your app or the opposite... With GC_ENABLE_INCREMENTAL (but without parallel marking), the collections are typically much shorter (see above) but the collections are more frequent (and the total collection pause time is bigger).
> I also really need to get out a new version; there is unfortunately some chance you are running into an old problem.
But, for now, it may sounds good to try your app with the CVS snapshot (at least, it isn't more unstable than any of gc v7).
- set GC_all_interior_pointers=0 before GC_INIT() (or build the collector without -DALL_INTERIOR_POINTERS) if you always preserve pointers to the beginning of alive objects.
- play with GC_free_space_divisor ("GC_FREE_SPACE_DIVISOR" env var) value.
More information about the Gc