isoalloc
isoalloc copied to clipboard
support of iso_alloc_from_zone to allocate a specified number of bytes and reserve memory for memory pooling
Is your feature request related to a problem? Please describe. I want to use the isoalloc as a kind of memory pool by usingh iso_alloc_from_zone. Unfortunately two things are missing for that:
- iso_alloc_from_zone isn't able to allocate a specified number of byte (_iso_alloc is).
- reserve/pre-allocate zone memory size passed by iso_alloc_new_zone
Describe the solution you'd like see above
Describe alternatives you've considered see above
Additional context see above
Sorry for the delayed response @daniel-brosche. Once a zone is created to allocate chunks of N bytes it cannot be changed. So creating a zone for chunks of size N and then trying to allocate chunks of size N+Y from it will not work. What you can do is create a private zone and build a simple bump allocator on top if it and then just destroy the zone when you're done with it. Take a look at this pool example, does it do what you need?
Not sure if I unserstand the example correctly. For me it seems that iso_alloc_new_zone create one block of memory which can be used in chunks by iso_alloc_from_zone. Does iso_alloc_new_zone preallocate the memory by the given allocation_size at once and then it is divided in chunks which are requested one after one by iso_alloc_from_zone?
Does iso_alloc_new_zone preallocate the memory by the given allocation_size at once and then it is divided in chunks which are requested one after one by iso_alloc_from_zone?
Yes. Can you provide some pseudo code of what you're looking to do?
I'm looking forward to memory pool functionality. Your pool example is a kind of object pool. Meaning the underlying chunks are fixed in size which is ok for fixed sized objects but not for dynamic sized objects like strings. Basically the size of the memory pool would be pre-allocated once and based on this reserved memory region iso_alloc would take the requested size of memory. E.g. pre-allocate 4MB and during runtime "allocate" from that region 1MB for a very large string.
Got it. Today IsoAlloc only supports fixed sized allocations out of any zone, private or public. So if a zone is created for chunks of size X bytes (where X is a power of 2), it can only ever return chunks of size X bytes. This is sort of fundamental to the design due to how the bitmap is constructed for managing those chunks. Id be open to creating an API that creates an unmanaged zone with a simple bump allocator abstraction on top of it. Of course you wouldn't be able to free chunks from it, only destroy the total zone.
Of course you wouldn't be able to free chunks from it
In my example above, does this mean it would be possible to allocate this large string of 1 MB and virtualy free and allocate later a string in size of 4MB (uses the whole size of the pre-allocated memory)? In my mind, this could virtualy be freed again to allocate other memory regions as long as it fits to the pre-allocated memory size.
Yes I think that would be doable. The implementation would just be a simple bump allocator on top of an IsoAlloc zone of a fixed size. lets say the zone size was 8MB. But in this design you can only really free the most recently allocated chunk, or all of the chunks. Free'ing a whole in the zone would require a different metadata scheme than what IsoAlloc has today.