Repository navigation
proposal: arena: add MakeMap #56230
Description
I noticed that making of Go maps was missing from the original proposal in #51317. The proposal says:
Another open issue is whether arenas can be used for allocating the elements of a map. This is
possible, but it is not clear what a good API would be. Also, there might be unusual cases if the arena used for the main map object is different from the arena used to allocate new elements of the map.
Perhaps I'm missing something, but couldn't we construct a Go map with an arena registered with it such that all allocations needed by the map are performed out of the arena? Thus, we're not directly allocating the elements of a map, but rather the entire map and (indirectly any map elements henceforth).
Something like:
// MakeMap creates a new map[K]V with the provided capacity.
// The map[K]V must not be used after the arena is freed.
// Accessing the underlying storage of the map after free may result in a fault,
// but this fault is also not guaranteed.
func MakeMap[K comparable, V any](a *Arena, cap int) map[K]V { ... }\cc @danscales
Reacted by Bryan C. Mills
Activity
bcmills commentedon Oct 14, 2022
CC @mknyszek
mknyszek commentedon Oct 14, 2022
I think this is the right way to do it, but I don't plan on implementing it any time soon. The map basically needs to carry an allocator around internally for whatever it might do (already a bit complex because we're so careful about how big the internal data structures are and how they fit into size classes), and then cloning the map out of the arena will be a bit complex too.
There was recently some discussion about actually supporting multiple map implementations under the hood for various use cases (I think this came up, possibly, in the context of SwissTables) in which case an interesting idea would be to have a map implementation specifically tailored to being created in an arena.
mknyszek commentedon Oct 14, 2022
By implementing it, I mean as part of the
GOEXPERIMENT.mknyszek commentedon Oct 15, 2022
I suppose in the same token that @rsc closed #56234, this should also probably be closed as a duplicate of #51317. I assume you meant that this issue and that one should go back into the original proposal, so I'll go ahead and reference this in #51317.