←back to thread

Understanding Memory Management, Part 1: C

(educatedguesswork.org)
237 points ekr____ | 1 comments | 13 Jan 25 14:16 UTC | HN request time: 0s | source
Show context
9999_points ◴[16 Jan 25 13:00 UTC] No.42724572[source]▶
Memory arenas should be taught to all programmers and become the default method of memory management.
replies(2): >>42724779 #>>42725034 #
_bohm ◴[16 Jan 25 13:47 UTC] No.42725034[source]▶
They're a great fit in many situations but certainly not all. Why not teach programmers a variety of allocation strategies and how to recognize when each might be a good fit?
replies(1): >>42725641 #
caspper69 ◴[16 Jan 25 14:32 UTC] No.42725641[source]▶
I initially read your username as boehm, and I was like wow, ok, this is a guy who knows his memory. :)

What situations would an arena allocator prove problematic or non-optimal, aside from the many allocations/deallocations scenario?

This is an area I'm very interested in, so any info would be appreciated.

replies(1): >>42727040 #
1. _bohm ◴[16 Jan 25 15:59 UTC] No.42727040[source]▶
In general, everything allocated within an arena has its lifetime tied to that arena. In lots of situations this is a fine or even desirable property (e.g., a single request context in a server application), but can be a tough restriction to work with in situations where you need fine-grained deallocations and possibly want to reuse freed space. The lifetime property can also be a pain to work with in multithreaded scenarios, where you might have multiple threads needing to access data stored in a single arena. Another situation that comes to mind is large long-lived allocations where you might want to have some manual defragmentation in place for performance reasons.