Steve Fink wrote: > Is there some way to make the default be that things will not get > moved around, and allow routines to volunteer to have their guts > scrambled if they know how to handle it?
A few random thoughts re buffers that don't wander around on their own: Create a new memory pool for immobile buffers (yes, we have a use for that flag at last) - I don't think we need different resource pools Immobile memory pools would have a new type of compactor function, that would maintain a linked list of free space (I suspect this would require multiple passes) Allocation would occur using one of the old-fashioned algorithms like first-fit This scheme may use more memory than copy-collection, due to fragmentation, and would obviously be slower for memory allocation, since it has to traverse a list of free blocks. In effect, it would be equivalent to using the operating system's memory allocation routine, except that we still retain GC control over it. However, being more expensive than the current Parrot allocation scheme may still be cheaper than a different homegrown solution every time somebody needs a buffer to stay put - the idea would be to use immobile buffers only when no more elegant solution is available for a specific problem, rather than have them as the default - most buffers should not be location sensitive? Alternatively, we say that buffers are, by definition, not location sensitive. Then we force the use of PMCs in those situations, and re-implement the original concept of telling a PMC to move its data to a new location. That would require scanning PMCs during memory pool compaction - at which point we are pretty close to unification of buffers and PMCs anyway?? Comments? -- Peter Gibbs EmKel Systems
