[throwaway894345]

Do I misunderstand what arenas are? I thought it was just "allocate this big array as a single allocation rather than N little allocations"? If so, how is that not supported in Go? (e.g., `arena := make([]Foo, 1000000000)`)

[slimsag]

An arena allocator allows you to store many allocations _of different types_ in the same single chunk of memory, and then free all of them at one point in time.

[throwaway894345]

Why can't you do this in Go? I'm 99% sure we can allocate a massive array of bytes using safe Go and use unsafe to cast a chunk of bytes to an instance of a type. This isn't type safe, but neither would the equivalent C code.

[slimsag]

That's what this whole thread is about: you can literally do just that.

[throwaway894345]

> That's what this whole thread is about: you can literally do just that

I don't know how you get that from the thread:

> Arenas are, however, unfeasible to implement in Go because it is a garbage collected language.

> If you are willing to use cgo, google already implemented one for gapid.

> there are other garbage collected languages like D, Nim and C# that offer the language features to do arenas without having to touch any C code.

It seems like the above statements implicitly or explicitly claim that this isn't feasible in Go without C.

[pjmlp]

You are misunderstanding the thread, I just mentioned some of the languages I like (still waiting for Go's generics), and the comment I was replying to made an assert about an implementation that uses cgo.

Both of us are dismissing the assertion that "Arenas are, however, unfeasible to implement in Go because it is a garbage collected language."

You can do manually memory allocation via a syscall into the host OS, use unsafe to cast memory blocks to the types that you want and then clean it all up with defer, assuming the arena is only usable inside a lexical region, otherwise extra care is needed to avoid leaks.

[throwaway894345]

Fair enough.

[shoefindortz]

I was proposing the cgo option because it's already implemented.

I _think_ allocating a slice of contiguous bytes and using unsafe pointers should work fine as long as you are very cautious about structs/vars with pointers into the buffer getting freed by the GC.

[throwaway894345]

> I _think_ allocating a slice of contiguous bytes and using unsafe pointers should work fine as long as you are very cautious about structs/vars with pointers into the buffer getting freed by the GC

Go's GC is conservative, so I don't think you need to take any special caution in that regard. I would expect that you just need to take care that your casts are correct (e.g., that you aren't casting overlapping regions of memory as distinct objects).