Hacker News Reader

Comment by sapiogram | Hacker News Reader

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?

View on HN

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.

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

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.

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?

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.

That is a really good question.

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!

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.

Reply on news.ycombinator.com