Dan Sugalski wrote:
At 6:02 PM +0100 12/21/02, Leopold Toetsch wrote:
And the memory get directly malloced from system.
Which argues against having it in one piece, unfortunately, as then we have the occasional need for one huge-ish chunk of memory. Damn.
I see.
... I wanted chunks attached to the pools originally, but that made marking rather expensive, as we had to do wacky bitmasking on the PMC pointer to get to the right entry in the pool mark slot.
Marking is not really done that often, e.g. 20000 DOD runs for 5E6 new pmcs. Reusing string headers shows much more speed improvement, then we would loose with slightly slower marking.
If we're doing a GC run, it's because we're out of something, potentially memory.
It's in the DOD run caused by a lack of headers normally but can be started, when the block allocator in resources.c is out of mem - yes.
It's the potential large size (which is a new concern) and the allocation of memory at GC time that troubles me, though the latter can be done at other times.
Ok, remaining is the potentially single huge chunk of mem.
If we can chunk the pool up somehow, that'd be good, though I know there's a speed penalty there.
Yep. leo
