20/01/2004 13:29:35, Gordon Henriksen <[EMAIL PROTECTED]> wrote: >On Monday, January 19, 2004, at 07:58 , [EMAIL PROTECTED] >wrote: > >> Is there any likelyhood that memory allocation will be hidden behind >> macros at two levels: >> - ALLOCPOOL() for allocating large chunks of memory (ppols) that are >> later sub-allocated (and managed) by: >> >> - SUBALLOC() for sub allocating within a pool > >Are you wanting something akin to Apache 2 pools, which are hierarchical >and designed to reduce path length when freeing blocks of objects? For >instance, all objects and sub-pools allocated during an HTTP request >cycle can be deallocated just by free()'ing the top-level request pool. > Nothing to do with Apache memory pools.
I believe that parrot already has the concept of memory pools in it's memory management. The idea is that by allocating similarly sized objects from separate (large) allocations, you can reduce the fragmentation of chunks and reduce the incidences where the memory need to be GC'd and compacted. Allocating an 8 byte chunk from a common memory pool is quite likely to nip a little off from a previously freed large chunk. When it comes time reallocate another chunk the same size as that large, freed chunk, although there is enough room in the over all freespace chain to accommodate it, the largest available chunk is now 8 bytes or so too small for the requirement. That induces either a compaction cycle or the need to extend the memory pool by the size of the large request. Allocating all small requests from the same pool, and large from another pool means that you are less likely to fragment the memory and more likely to be able to re-use an existing slot in the free-space chain for any given request. If the allocation of pools, and the allocation of bit-of-a-pool, are macroised, it makes it possible for OS's where there are multiple APIs for memory allocation to bypass the CRT memory allocation routines and use which ever native APis are best suited for the type of allocation. Personally, I would like to see memory allocation for each class type be managed by the class constructor itself. This would theoretically allow each class that has a fixed instance size to manage it's own pool on OS's where that makes sense. The class would allocate a pool for itself when loaded and then allocate instances from that pool on new() and deallocate upon DESTROY. If it's memory pool was exhausted when new was called, it would invoke the GC on *it's pool only*. This separation would mean that each run of the GC would have a much smaller pool of memory to compact and garbage collect when it was invoked. It would also be less likely to be called, as each allocation from a pool of fixed sized sub allocations will only ever need to call the GC when it's pool is entirely exhausted. But that is a radical departure :), so if would just like to see separate calls for pool allocation/reallocation and element allocation/reallocation, rather than having calls to malloc() scattered through out the codebase. > >I don't think parrot could make use of that model, since it can't very >well guarantee that the user cannot retain references past the lifetime >of the pool. Apache trusts modules not to make such errors; parrot can't >trust the byte-code it's executing any further than it can throw it. A >generational collector is a more likely means by which parrot might >reduce memory-related overhead. > > > >Gordon Henriksen >[EMAIL PROTECTED] > > Nigel/
