[Gc] GC in "soft" real time
hans.boehm at hp.com
Thu Aug 26 17:08:58 PDT 2010
If you're in a position to look around in your application with a debugger, it may be worth looking at the size of the root set being scanned by the collector, and whether it's easy to exclude (with GC_exclude_static_roots) large regions of that that can't possibly contain pointers to the garbage-collected heap. GC_dump() will tell you about the root sections, among other things. Getting the extension language implementation to make more use of GC_malloc_atomic may have a similar effect, especially if it allocates large pointer-free objects. With luck, those might help you dodge the issue, if you haven't already tried that.
The only concern I would have about implementing a pool outside the GC in this case is that
1) It may not reduce GC times much, though it probably will greatly reduce their frequency.
2) You have to think about whether or not it can contain pointers to the garbage-collected heap, and hence should be traced. If so, you may want to avoid tracing from dead objects in the pool. In any case, you should think about where the pool memory comes from.
I don't see a great argument for implementing this inside the GC, though we may want to think about making it easier to scan only live objects inside such a pool, if that's really an issue. (I suspect the best way to do that currently is to allocate the pool from the garbage collector as a custom "kind", with a user-defined mark function. This is probably harder than it should be.)
> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> On Behalf Of Jim Hourihan
> Sent: Thursday, August 26, 2010 10:03 AM
> To: gc at linux.hpl.hp.com
> Subject: [Gc] GC in "soft" real time
> We've been using the GC in our cross platform app for a few years now,
> and its been great. But in the process we've starting using it *too*
> much inside of a render loop (~60Hz at its fastest, usually 24). So
> collection is taking longer than .03 seconds for us on windows in
> particular. On mac and linux its still under the limit.
> I had a thought about our particular use case which I'm not sure is
> directly applicable to the GC library itself or not.
> Basically, we've observed that *all* of the memory allocated during the
> critical rendering loop can be immediately reclaimed. No object
> allocated during that time is retained. The obvious solution is
> allocate from a pool (e.g. objc autorelease) and free it all on return
> from the rendering code. (I'm sure there is a term-of-art for this that
> I don't know.)
> So my question is: is this something that makes sense to do in the
> context of the GC library (because of issues I don't know about) or
> should this type of thing be implemented outside of it.
> A little bit of context: the GC is being used by our extension language
> which is making OpenGL calls. Its not being used for all memory
> management in the app.
> Thanks for any help.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc