On Mon, 24 Sep 2001, Uri Guttman wrote: > >>>>> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes: > > AB> If you are interested, I'll try to get a copy of the paper to you. > AB> It has some interesting ideas. By having 'arenas' for each object > AB> type, you can remove a large part of the overhead of > AB> splitting&recombing memory cgunks. The perl5 allocator already > AB> does something similar. > > sounds like a wheel worth looking at. are there working free C libs that > implement it? how much work is it to write a new one that is > parrot-centric? would we need all of it features that manage other > things? i assume that the segmented stacks would also use arenas like > this. we will need to define our set of arenas and sizes at some point. > > we haven't touched threads and malloc. does each thread want its own > arena so we don't need locking? > Interesting idea. The main allocator could be locked, so long as x% of all allocations come from thread-specific arenas. The only problem is that this adds overhead to creating / deleting threads (setting up / freeing arena chunks). This would only be efficient if the main allocator only returned chunks on the order of a page-size (which is then divided up into smaller granuled arenas by the parallel procssing threads). Another method would be to act like databases do - You finely tune your memory allocator so that you only perform regional locks. You also point threads to different starting / insertion points along the memory chains. This way you have a unified memory allocation scheme with only occasional contention locks. If all your data-structures are in large chunks (on the order of a page), then this would do well. (Though it might require architecture specific test-and-set operations for efficiency). -Michael
