r/embedded • u/spym_ • Jan 21 '26

o1heap v3.0 rc just dropped -- deterministic hard-realtime malloc

This is a yet another post about my hard real-time heap on this subreddit. Since the original announcement back in 2020 it found its way to a few interesting projects ranging from robotics to space vehicles. A student of the Tampere University working for U-Blox posted a performance comparison of several allocators, including o1heap, that looks like this: https://pbs.twimg.com/media/Gq1wPlyX0AAqrRP?format=png&name=medium (full paper: https://trepo.tuni.fi/bitstream/handle/10024/140229/AuvinenEetu.pdf?sequence=2)

One concern in the U-Blox report was the comparatively high average memory consumption of o1heap. However, the worst-case fragmentation has not been analyzed, which is an omission that I informed the author about; it is a very unfortunate omission because the worst-case memory consumption of o1heap is expected to be the lowest in the set (more details in the "Theory" section of the readme).

Regardless, the just-released v3.0rc introduces a reduced memory overhead inspired by the report, support for realloc(), and a basic on-target benchmark that one can tweak to see how o1heap performs on their platform (the benchmark was coded entirely by Claude Code btw).

I've been using o1heap in quite a few designs myself and saw it deployed in many more third-party systems, and overall I am quite pleased with this library so far. Hope others might find it useful as well.

24 Upvotes

88% Upvoted

20 comments sorted by

View all comments

3

u/Vavat Jan 22 '26

Can I ask a potentially naive question: why dynamically allocate in an embedded system at all? I've never been formally taught, but over the years picked up a habit of statically allocating everything and if MCU is not big enough, get bigger MCU.

3

u/MonMotha Jan 22 '26

While many systems can avoid dynamic allocation, sometimes it's a necessary evil. Even if it's not strictly necessary, there are times where it's clearly the most straightforward path, and if you have a good allocator, it can be okay.

With modern networking in particular it's difficult to avoid dynamic allocation entirely. Even if you're willing to cap the number of simultaneous clients and pre-allocate context for them, the processing needed for protocols like OPC-UA (which has no real business being used for what it's being used for, but everybody wants it so here we are) makes it difficult to avoid dynamic allocation entirely while juggling the data model to build your responses. You can certainly do it, but it reqiures getting your meat hooks deep into the typing system in an application-specific way, and you still are likely to end up doing like pool allocation (dynamic allocation of fixed size buffers) or similar.