3 ms·

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."

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."