4 ms·

I might be a bit ignorant here, but I was under the impression that this is what every program already does. Before virtual memory, you would not call into the

I might be a bit ignorant here, but I was under the impression that this is what every program already does. Before virtual memory, you would not call into the operating system for every allocation but you would have an in-process memory allocator that obtains large chunks of memory from the operating system and satisfies allocations from that pool. The advent of virtual memory removed the need to explicitly obtain memory from the operating system, just access it and the page fault handler will transparently give you some memory. But you still would have an allocator that keeps track of all your allocations. Even the use of a garbage collector would not fundamentally change this. If I am not misunderstanding what this project tries to do, then they are essentially adding another layer, they get large chunks from the allocator and then use those to satisfy allocations. This seems essentially like having a second allocator on top of the existing one. If the existing one does not work well in certain scenarios, there might be some performance to be gained by using a different allocator, even on top of the existing one. But I wonder if this is the best way to solve the issue, this seems more like a workaround than a fix. Would it not be better to tune the existing allocator or make it configurable or even swappable? This of course requires more fundamental changes - language, runtime, compiler - instead of just being a library. Or maybe Go already has facilities to customize memory management? EDIT: I think I got this wrong, the actual goal seems to be able to allocate several objects in a continuous chunk of memory, i.e. an array of objects - not to be confused with an array of pointers to objects - for improved locality.

Someone 3y ago
Arena allocators add the ability to free all allocations in an entire arena with a single call. That means that you don’t have to keep track of allocations made. That can simplify APIs that take and/or produce pointers. They also allow you to have multiple arenas. A use case is a web server, where each request creates an arena, allocates scratch memory in it, and destroys the arena after handling the request.
sapiogram 3y ago
> I might be a bit ignorant here, but I was under the impression that this is what every program already does. It is not. Arena allocators have a fundamentally different API, because they don't allow you to de-allocate individual objects in the arena - everything must be de-allocated at once. For specific workloads, like repeatedly allocating a large number of short-lived objects, this can be a huge speedup, and also significantly reduce memory usage.
- danbruc 3y ago
  So it is like allocating an array of objects but I guess it does not have to be homogeneous, i.e. you can decide after the initial allocation what objects you want to live in your chunk of memory. Allocation gets simpler as you just have to move one pointer forward past the newly allocated object. Memory usage would actually remain the same or even increase - ignoring the overhead of data structures to track allocations - as the lifetime of objects is now tied to the lifetime of the arena. You could get essentially the same behavior from a normal per-thread allocator if you never freed anything and the allocator would satisfy all allocations from a single pool. You would of course still pay the management overhead and have to free every object individually. More interesting scenarios arise when you use several arenas with different lifetimes or mix arenas allocation with normal allocation.
- nickpsecurity 3y ago
  What you say is true for pure arenas. There are also hybrids like Immix that mix them with other methods: https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/immix/ https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/immix/
  - sapiogram 3y ago
    I only took a brief look, but from an API perspective, this seems identical to "normal" garbage collectors? In the sense that from the programmer's perspective, all the allocations live forever?

Someone 3y ago

Arena allocators add the ability to free all allocations in an entire arena with a single call. That means that you don’t have to keep track of allocations made. That can simplify APIs that take and/or produce pointers. They also allow you to have multiple arenas. A use case is a web server, where each request creates an arena, allocates scratch memory in it, and destroys the arena after handling the request.

sapiogram 3y ago

> I might be a bit ignorant here, but I was under the impression that this is what every program already does. It is not. Arena allocators have a fundamentally different API, because they don't allow you to de-allocate individual objects in the arena - everything must be de-allocated at once. For specific workloads, like repeatedly allocating a large number of short-lived objects, this can be a huge speedup, and also significantly reduce memory usage.

danbruc 3y ago
So it is like allocating an array of objects but I guess it does not have to be homogeneous, i.e. you can decide after the initial allocation what objects you want to live in your chunk of memory. Allocation gets simpler as you just have to move one pointer forward past the newly allocated object. Memory usage would actually remain the same or even increase - ignoring the overhead of data structures to track allocations - as the lifetime of objects is now tied to the lifetime of the arena. You could get essentially the same behavior from a normal per-thread allocator if you never freed anything and the allocator would satisfy all allocations from a single pool. You would of course still pay the management overhead and have to free every object individually. More interesting scenarios arise when you use several arenas with different lifetimes or mix arenas allocation with normal allocation.
nickpsecurity 3y ago
What you say is true for pure arenas. There are also hybrids like Immix that mix them with other methods: https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/immix/ https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/immix/
- sapiogram 3y ago
  I only took a brief look, but from an API perspective, this seems identical to "normal" garbage collectors? In the sense that from the programmer's perspective, all the allocations live forever?