Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support of iso_alloc_from_zone to allocate a specified number of bytes and reserve memory for memory pooling #198

Open
daniel-brosche opened this issue Jun 14, 2023 · 7 comments

Comments

@daniel-brosche
Copy link

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:

  1. iso_alloc_from_zone isn't able to allocate a specified number of byte (_iso_alloc is).
  2. 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

@struct
Copy link
Owner

struct commented Jul 5, 2023

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?

@daniel-brosche
Copy link
Author

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?

@struct
Copy link
Owner

struct commented Jul 22, 2023

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?

@daniel-brosche
Copy link
Author

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.

@struct
Copy link
Owner

struct commented Aug 5, 2023

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.

@daniel-brosche
Copy link
Author

daniel-brosche commented Aug 7, 2023

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.

@struct
Copy link
Owner

struct commented Aug 12, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants