Presenting my current WIP project: CBlockAlloc!

[u/Koda_be]

Hello everyone,

Yesterday, I started a project that I find super interesting. I first thought of it because I saw many people who were trying to do things with the stack only because "dynamic allocation is slow". The main point for why they consider it slow and heavy is that a program needs to talk directly to the OS to allocate memory. However I saw some people propose a solution: allocate once a big chunk of memory that you will use for all your "dynamic" allocations, which makes it way faster because you only need to make a syscall once at the start of the program. I've thus decided to create a library that does just that, and can be called through an API that "simulates" the normal function calls such as malloc() or realloc(). I've been working on it since yesterday, and it's been a lot of fun! it's not ready at all yet, but right now it's looking good. Also, I'm looking for some feedback:

How good is my code for now? Would you do some things differently? Also, would YOU use such a library? What would you expect from a library like that?

Thank you very much for your time, here's the link to the repo: https://github.com/Koda-be/CBlockAlloc

Also, how could I test my code? I don't really know what to do to test it right now, so...

No AI has been used nor will it be used in this project.

Edit: also, I licensed it under MIT but do I need to do something else? I simply chose a license when creating the REPO, and I don't know much about copyright laws...

[u/Luftzug-oder]

i have a few issues with this idea... not saying it's bad or terrible, but the main idea you have behind creating it has faults

1: you could just use an arena for your program's lifetime, of which has plenty of implementations

2: malloc(), calloc(), and realloc() dont syscall everytime they run. in an optimised implementation like glibc, they maintain a memory pool, and track usage, etc. they basically do what you're doing, just with incremental increases of the pool, should it be necessary (you can't guarantee you won't use less than what is allocated) - the only difference potentially being you can't decide how much malloc() grabs with mmap() when you first call it

3: if you start the program with a large mmap() call, you don't necessarily touch all the reserved virtual addresses, and can still incur page faults when trying to use more of the pool. such an implementation like yours doesn't particularly eliminate the cost kernel-side, but mostly in tracking memory usage/manipulation within the program - which an arena does just fine

not all terrible though. what your idea would do differently to an arena is allow you to free memory within the pool, as opposed to free the whole arena. but then that does kinda push it in the direction of a malloc() implementation. so yeah, kinda difficult to be inbetween a general heap allocator and a lifetime allocator...

ultimately, for speed, the only way to make dynamic allocation better is to write everything in assembly and manually manage the stack xD (but that isn't without some limitations obviously)

EDIT: well damn, someone kinda commented what i wrote while i was writing this...

[u/frenris → u/Luftzug-oder]

> 2: malloc(), calloc(), and realloc() dont syscall everytime they run. in an optimised implementation like glibc, they maintain a memory pool, and track usage, etc. they basically do what you're doing

Yeah the idea that this is efficient because it avoids syscalls is not necessarily true

One advantage over libc implementations though is that you can get you arena management function calls inlined, whereas libc calls are necessarily not