In case it may be usefull to someone: I stumbled on an interesting pool-based GC designed by someone having soft realtime applications in head:
http://old.notam02.no/arkiv/src/rollendurchmesserzeitsammler-0.1.1.tar.gz http://www.notam02.no/index.php?/nor/Teknologi-og-tekst/Programvare/Audio-Rollendurchmesserzeitsammler http://www.notam02.no/index.php?/nor/Teknologi-og-tekst/Programvare/Audio-Rollendurchmesserzeitsammler-Updates The first release was not pool based but two-level segregate and fit, ( http://rtportal.upv.es/rtmalloc/ ) the tlsf code is still in but unused without a compile option. The GC interface seems to be the same as boehm GC, altough I never used any, so you are the judge. Regards. (! URLs will probably wrap) On Thu, Mar 5, 2009 at 5:24 PM, Jonathan S. Shapiro <[email protected]> wrote: > > On Thu, Mar 5, 2009 at 12:51 AM, Pal-Kristian Engstad > <[email protected]> wrote: > > > However, at least in my industry, the common way to perform allocation > > is to make use of "pools". Essentially, you pre-allocate a large block > > of memory for a specific task. > > For a specialized application (and your case certainly qualifies), it > is often possible to design a specialized allocator that meets the > needs of that application particularly well. Comparing this sort of > specialized allocator to a general-purpose allocator is something of > an "apples and oranges" comparison. > > That having been said, a proper GC implementation *should* be > extremely competitive with the particular pool design that you > describe: > > > Another typical use-case is the double-buffering scheme. You allocate > > two of the above memory pools, one for each frame. Since you know that > > after a frame has been drawn the memory is no longer needed, you simply > > reset the pointers. > > Having multiple pools (that is: disjoint GC domains) is certainly not > a big complication, and I think that it is a very interesting issue to > look at. For this and some other reasons, I'm looking again at the > region management question. If there are indeed no references into the > pool at the end of the frame, then GC'ing that pool should occur in > unit time, which is very close to what you get now. > > But speaking more generally, the question of how to go about > supporting more specialized deallocation schemes raises a deep issue > that needs attention. I think we should all look at it together, but > **not yet**. I will get sucked into that discussion in a serious way, > and it will delay the first release. The only piece that we need to > deal with quickly is to establish a syntax for "placed" allocation: > allocation that occurs from a known or specified pool. > > I propose that we hold on the placed allocation question until the > syntax question stabilizes a little, so that we can have it once > instead of multiple times. > > shap > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
