Sean O'Rourke wrote: > But really I think the way to go would be a generational collector -- after > we've collected a pool once or twice (or after we've failed to recover > more than x% from it on the previous run), we put it off to the side and > compact (indeed, look at) it less often. New objects are allocated from a > new pool, since they are less likely to live past the next collection than > ones that have already been around awhile.
For now I am going to continue trying to keep the current system functioning reasonably efficiently. As long as we keep the API small and simple, we should be able to plug in a totally redesigned system later. We are getting to the stage now where Parrot is becoming fairly usable, although the PMC architecture still needs some revision, and therefore should be able to start getting a better idea of the demands that are going to be made on the memory manager. I have briefly read the CMM paper, and have downloaded the code to have a proper look at it sometime. When I get further along with the design process of the next generation I will post it for comments; in the mean time please feel free to contribute any ideas you have (or, better still, just write the thing - I really don't mind!) -- Peter Gibbs EmKel Systems
