4 ms·

For compilers, arena allocation is king. IMHO: arenas > GC > RAII > malloc/free. With manual memory management (whether RAII or not), it's usually not difficul

by ynik 3y ago

For compilers, arena allocation is king. IMHO: arenas > GC > RAII > malloc/free. With manual memory management (whether RAII or not), it's usually not difficult to add arenas into the mix. On the other hand, in GC languages: many GCs only allow heap pointers to the beginning of objects, not to their interior. This means arenas can't used in those GC languages; every full collection actually has to trace the millions of AST nodes individually.

BulgarianIdiot 3y ago
Any memory model that's not recursive (i.e. arenas within arenas ... within arenas) is deeply unserious to me.
- dathinab 3y ago
  You can allocate a part of a arena to form a new arena, at least theoretically. And in many cases for compliance you want to 1) limit the memory a specific sub-component of your code can use 2) make sure it always can have this memory 3) make sure it doesn't leak any memory ever. Arenas are probably the most reliable way to archive this. The main problem is if the sub-component needs to allocate memory which outlives it's life time. A common way around this is that the component delegating work to it has to provide that memory (e.g. windows kernel API) but that doesn't always scale well. Another is to use another memory management for it (e.g. GC) but then it isn't enforcing compliance anymore. Etc. it's always some compromis.
  - BulgarianIdiot 3y ago
    Allocating within the given arena is simply an option. You can still be a component owning an arena, but delegate the allocation to an ancestor/sibling context/arena if you want that allocation to outlive you.
    - dathinab 3y ago
      One of the various things I placed in the `Etc.` ;=) But like all the other things listed it's not perfect. For example if I just pass a unconstrained access to a other components arena to a component you can no longer "guarantee" that the component doesn't leak anything as it could use the arena to allocate things besides the thing for which it was passed it to the component. So now you need to have additional steps to assure this isn't happening if you want to make sure as much as possible that everything is compliant. Through depending on what you do this aren't necessary complicated additional steps through it really depends.
      - BulgarianIdiot 3y ago
        In this model you can't pass access. It's not like "here's the key and drive the Ferrari", it's instead "tell me where you want to go, and I'll drive you there. Or not."
dathinab 3y ago
yes, But also rusts ownership model isn't just about memory management (more state management which includes resource management which includes memory management). And IMHO for resource management "in general" implicit semi-manual type checks scope based resource management works the most reliably (rust ownership model is more then just RAII). Arenas can be good too, but aren't applicable always and tend to make things more complicated to get right. Similar for GC, it can work well in some cases, but just in some and in others it's prone to resource leakage and getting dependencies right is hard. So in my view memory management is just a special case of resource management where arenas happen to be very widely applicable and where for GCs people put a lot of work in to "get it right".

by ynik 3y ago

BulgarianIdiot 3y ago

Any memory model that's not recursive (i.e. arenas within arenas ... within arenas) is deeply unserious to me.

dathinab 3y ago
You can allocate a part of a arena to form a new arena, at least theoretically. And in many cases for compliance you want to 1) limit the memory a specific sub-component of your code can use 2) make sure it always can have this memory 3) make sure it doesn't leak any memory ever. Arenas are probably the most reliable way to archive this. The main problem is if the sub-component needs to allocate memory which outlives it's life time. A common way around this is that the component delegating work to it has to provide that memory (e.g. windows kernel API) but that doesn't always scale well. Another is to use another memory management for it (e.g. GC) but then it isn't enforcing compliance anymore. Etc. it's always some compromis.
- BulgarianIdiot 3y ago
  Allocating within the given arena is simply an option. You can still be a component owning an arena, but delegate the allocation to an ancestor/sibling context/arena if you want that allocation to outlive you.
  - dathinab 3y ago
    One of the various things I placed in the `Etc.` ;=) But like all the other things listed it's not perfect. For example if I just pass a unconstrained access to a other components arena to a component you can no longer "guarantee" that the component doesn't leak anything as it could use the arena to allocate things besides the thing for which it was passed it to the component. So now you need to have additional steps to assure this isn't happening if you want to make sure as much as possible that everything is compliant. Through depending on what you do this aren't necessary complicated additional steps through it really depends.
    - BulgarianIdiot 3y ago
      In this model you can't pass access. It's not like "here's the key and drive the Ferrari", it's instead "tell me where you want to go, and I'll drive you there. Or not."

dathinab 3y ago

yes, But also rusts ownership model isn't just about memory management (more state management which includes resource management which includes memory management). And IMHO for resource management "in general" implicit semi-manual type checks scope based resource management works the most reliably (rust ownership model is more then just RAII). Arenas can be good too, but aren't applicable always and tend to make things more complicated to get right. Similar for GC, it can work well in some cases, but just in some and in others it's prone to resource leakage and getting dependencies right is hard. So in my view memory management is just a special case of resource management where arenas happen to be very widely applicable and where for GCs people put a lot of work in to "get it right".