_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Show HN: I wrote a minimal memory allocator in C
rurban wrote 3 hours 27 min ago:
One line: bump sbrk(). Done.
No need to free in short living processes
matheusmoreira wrote 1 hour 5 min ago:
The fastest garbage collector algorithm is similar. Just keep
allocating new objects. Just don't bother with actually collecting
garbage. Just leak all that memory.
Perfectly usable in many applications. Unfortunately, since it
depends on assumptions about the application, it's not really suited
for a general purpose library.
canyp wrote 4 hours 49 min ago:
I always like me some memory allocator blog/code. Two links in the
context of gamedev below, in case you or anyone else is interested. [1]
[2] I also don't know how much we want to butcher this blog post, but:
> RAM is fundamentally a giant array of bytes, where each byte has a
unique address. However, CPUs donât fetch data one byte at a time.
They read and write memory in fixed-size chunks called words which are
typically 4 bytes on 32-bit systems or 8 bytes on 64-bit systems.
CPUs these days fetch entire cache lines. Memory is also split into
banks. There are many more details involved, and it is viewing memory
as a giant array of bytes that is fundamentally broken. It's a useful
abstraction up until some point, but it breaks apart once you analyze
performance. This part of the blog didn't seem very accurate.
URI [1]: https://screwjankgames.github.io/engine%20programming/2020/09/...
URI [2]: https://www.bytesbeneath.com/p/the-arena-custom-memory-allocat...
writebetterc wrote 45 min ago:
In a single-threaded context, I think 'giant array array of bytes' is
still correct? Performance, not so much.
> This part of the blog didn't seem very accurate.
It was a sufficient amount of understanding to produce this allocator
:-). I think that if we have beginner[0] projects posted and upvoted,
we must understand that the author's understanding may be lacking
some nuance.
[0] author might be a very good programmer, just not familiar with
this particular area!
Subsentient wrote 5 hours 24 min ago:
As soon as I saw mmap(), I knew this wasn't a true native allocator. So
yeah, not quite so insightful after all.
matheusmoreira wrote 1 hour 8 min ago:
How so? All production memory allocators use mmap nowadays. That's as
native as it gets outside of the kernel. What were you expecting?
leecommamichael wrote 4 hours 48 min ago:
Your comment reads as if you believe that simply writing the syscall
C wrapper yourself would constitute a meaningful enhancement to the
code. We can all apply more effort to be insightful.
vintagedave wrote 5 hours 10 min ago:
Itâs a âminimalâ allocator. Reading the blog it seems to be
going in depth into allocator principles, in practice, things like
coalescing blocks.
I havenât read in full so not sure if it discusses using blocks vs
other structures (eg stack-based allocators, stack being the data
structure not the program stack.) Ie, itâs a set of implementation
choices. It still seems to reflect common ways of allocating in far
more detail than many blogs Iâve read on the topic do.
AdieuToLogic wrote 6 hours 8 min ago:
Why redeclare the function signatures in allocator.h[0] when they must
match what is already defined by the C standard?
Since this is all allocator.h[0] contains aside from other include
statements, why have allocator.h at all?
0 -
URI [1]: https://github.com/t9nzin/memory/blob/main/include/allocator.h
matheusmoreira wrote 55 min ago:
Why match the C standard at all? The C standard library is not really
a shining example of API design.
It's interesting to brainstorm new memory allocation interfaces. Some
cool ideas: [1] [2] I'm in a position to do this in my programming
language project. Wrote my own allocator for it. Maybe it's time to
reinvent a better wheel.
URI [1]: https://nullprogram.com/blog/2023/12/17/
URI [2]: https://gist.github.com/o11c/6b08643335388bbab0228db763f9921...
leecommamichael wrote 4 hours 43 min ago:
Why write a mini allocator?
checker659 wrote 6 hours 56 min ago:
That project structure is reminding me of claude.
leecommamichael wrote 4 hours 45 min ago:
Personally Iâd not bother with folders, but to each their own.
Iâm sorry but I just donât see what youâre onto.
gameman144 wrote 4 hours 46 min ago:
Could you elaborate? The project structure looks extremely normal to
me, but I don't know if I'm overlooking red flags all over the place.
checker659 wrote 3 hours 55 min ago:
The structure in the README.md (not the actual structure).
keyle wrote 6 hours 33 min ago:
So does half the readme
leecommamichael wrote 4 hours 44 min ago:
Which part?
achierius wrote 8 hours 9 min ago:
Looks nice! Though I have to say, you should probably avoid sbreak even
for small allocations -- obviously it's slow, but even beyond that you
have to deal with the fact that it's essentially a global singleton and
introduces a lot of subtle failure cases you might not think of + which
you can't really solve anyways. It's better to mmap out some chunk of
memory and sub-allocate it out yourself.
macintux wrote 7 hours 26 min ago:
Can you supply an example of a failure case that canât be solved
(or is at least challenging to solve)?
sweetjuly wrote 6 hours 17 min ago:
sbrk grows linearly, and if anything is mapped in the way it fails.
mmap can map anywhere there's space as it is not restricted to
linear mappings. So, you'd better hope a mapping doesn't randomly
land there and run you out of space.
It's not a failure but relatedly as sbrk is linear, you also don't
really have a reasonable way to deal with fragmentation. For
example, suppose you allocate 1000 page sized objects and then free
all but the last one. With an mmap based heap, you can free all 999
other pages back to the OS whereas with sbrk you're stuck with
those 999 pages you don't need for the lifetime of that 1000th
object (better hope it's not long lived!).
Really, sbrk only exists for legacy reasons.
ori_b wrote 5 hours 53 min ago:
> With an mmap based heap, you can free all 999 other pages back
to the OS whereas with sbrk you're stuck with those 999 pages you
don't need for the lifetime of that 1000th object (better hope
it's not long lived!).
Thanks to the wonders of virtual memory, you can
madvise(MADV_DONTNEED), and return the memory to the OS, without
giving up the address space.
squirrellous wrote 5 hours 18 min ago:
Not giving up the address space feels like an anti feature.
This would mean, among other things, that access to the
DONTNEED memory is no longer a segfault but garbage values
instead, which is not ideal.
quibono wrote 8 hours 15 min ago:
I hate that very often my first reaction to Show HN posts like this is
to cynically look for signs of blatant AI code use.
I don't think that's the case here though.
DIR <- back to front page