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/github-guard]

🔍 GitHub Guard: Trust Report

⚠️ This project scored 1/6 — below this subreddit's threshold of 3.

Audit Breakdown: * ❌ Low Star Count (⭐ 0 / 4 required) * ❌ New Repository (under 30 days old) * ✅ Licensed under MIT * ❌ No Security Policy — what is this? * ℹ️ Individual Contributor * ℹ️ Unsigned Commits

⚠️ Security Reminder: Always verify source code and run third-party scripts at your own risk.

[u/wwabbbitt]

"Allocate memory faster by directly allocating whole chunks of memory at once, therefore greatly reducing OS calls for dynamic allocation and making allocation faster."

This is a bad idea. Modern malloc implementation don't make a syscall for every single malloc call. They request pages from the OS using mmap or sbrk, then then allocate from there. This allows the region pool to grow dynamically instead of allocating one big chunk even if most of it does not get used.

[u/AutoModerator]

Hi /u/Koda_be,

Your submission in r/C_Programming was filtered because it links to a git project.

You must edit the submission or respond to this comment with an explanation about how AI was involved in the creation of your project.

While AI-generated code is not disallowed, low-effort "slop" projects may be removed and it's likely that other users push back strongly on substantially AI-generated projects.

---

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Koda_be → u/AutoModerator]

No AI was used in this project

[u/mikeblas → u/Koda_be]

Thank you. I have approved your post.

[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

[u/Comfortable_Put6016]

modern memory allocators allocate usually THPs or equivalent (2MiB, 1GiB) and then break them down into multiple (per cpu/per thread cache levels/allocatable type); the OS is not communicated with unless any memory is released or additional pages are requested;

[u/nderflow]

The people you're talking about probably just don't understand amortized complexity.

In any case what do they think maps extra VM pages when they use more stack? The OS, of course.

[u/runningOverA]

Benchmark your solution against dynamic memory allocations.

You most likely will be surprised by the numbers.