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
