7 ms·

Looks like the arena is completely unsound if you mix types with different alignments? arena := NewSlabArena(8182, 1) // 8KB var b *byte = New[byte](arena

Looks like the arena is completely unsound if you mix types with different alignments? arena := NewSlabArena(8182, 1) // 8KB var b *byte = New[byte](arena) var i *int = New[int](arena) fmt.Printf("Pointer address: %p\n", b) fmt.Printf("Pointer address: %p\n", i) Result: Pointer address: 0x14000198000 Pointer address: 0x14000198001 I'm not a Go language lawyer, but I assume this is just immediate UB. OP, it's fine to publish a library without experience in manual memory management, but maybe put a disclaimer in the README?

perbu 3y ago
There is also the issue where you have a pointer in the arena pointing to something on the heap. The GC will gladly kill the object on the heap as it has no idea something is still pointing to it.
- throwaway894345 3y ago
  Why wouldn't this just use generics to allocate a big slice of the type so that the GC can know whether or not the arena may contain pointers to the heap?
  - jerf 3y ago
    You can do that but you end up with something other than what the author wrote. The use cases are different. Arenas, at least in principle, should generally be able to allocate anything, not just a single type. If you have a single type you would do the equivalent thing in any language, not use arenas.
  - perbu 3y ago
    That is a really good question.
  - jfindley 3y ago
    Generics in go, as they're implemented today, sadly have a fair bit of performance overhead. I haven't tried but my assumption would be that go generics are not fast enough to make an effective arena allocator. I'd be thrilled if someone could prove me wrong though!
    - throwaway894345 3y ago
      The performance overhead is when you're calling a method on the generic type--Go has to lookup the specific implementation in a dictionary. Pretty sure that doesn't apply for straight-up container use cases like this one.
electroly 3y ago
The fact that the author calls it a slab arena makes me think they did, indeed, intend for it to be used with a single type per arena. I do wonder why you'd want an allocator that is both slab and arena, though. I assume there is some use case but nothing immediately comes to mind.
- sapiogram 3y ago
  > The fact that the author calls it a slab arena makes me think they did, indeed, intend for it to be used with a single type per arena. Maybe? But that seems strange, since they seem to have intended it to be used for http servers making per-request allocations. Come to think of it, the arena is probably still unsound with just ints, because the underlying allocation is just for a `[]byte`, which I don't think is guaranteed to be aligned to 8 bytes. Might be on most platforms, though.

perbu 3y ago

There is also the issue where you have a pointer in the arena pointing to something on the heap. The GC will gladly kill the object on the heap as it has no idea something is still pointing to it.

throwaway894345 3y ago
Why wouldn't this just use generics to allocate a big slice of the type so that the GC can know whether or not the arena may contain pointers to the heap?
- jerf 3y ago
  You can do that but you end up with something other than what the author wrote. The use cases are different. Arenas, at least in principle, should generally be able to allocate anything, not just a single type. If you have a single type you would do the equivalent thing in any language, not use arenas.
- perbu 3y ago
  That is a really good question.
- jfindley 3y ago
  Generics in go, as they're implemented today, sadly have a fair bit of performance overhead. I haven't tried but my assumption would be that go generics are not fast enough to make an effective arena allocator. I'd be thrilled if someone could prove me wrong though!
  - throwaway894345 3y ago
    The performance overhead is when you're calling a method on the generic type--Go has to lookup the specific implementation in a dictionary. Pretty sure that doesn't apply for straight-up container use cases like this one.

electroly 3y ago

The fact that the author calls it a slab arena makes me think they did, indeed, intend for it to be used with a single type per arena. I do wonder why you'd want an allocator that is both slab and arena, though. I assume there is some use case but nothing immediately comes to mind.

sapiogram 3y ago
> The fact that the author calls it a slab arena makes me think they did, indeed, intend for it to be used with a single type per arena. Maybe? But that seems strange, since they seem to have intended it to be used for http servers making per-request allocations. Come to think of it, the arena is probably still unsound with just ints, because the underlying allocation is just for a `[]byte`, which I don't think is guaranteed to be aligned to 8 bytes. Might be on most platforms, though.