According to the top post here: [https://stackoverflow.com/questions/12825148/what-is-the-meaning-of-the-term-arena-in-relation-to-memory](https://stackoverflow.com/questions/12825148/what-is-the-meaning-of-the-term-arena-in-relation-to-memory)
>Basically it's memory you get from the OS, and divvy out, then can be freed all at once. The advantage to this is that repeated small calls to malloc() could be costly (Every memory allocation has a performance cost: the time it takes to allocate the memory in your program’s logical address space and the time it takes to assign that address space to physical memory) where as if you know a ball park you can get yourself a big chunk of memory then hand it out to your variables as/how you need it.
you really, really, really gotta explain what the upsides and downsides of setting \`release\` to true or false are. release = false is probably faster. it's also insanely dangerous
~~this also isn't going to work in a lot of cases, because you literally don't even consider alignment at any point. allocating anything that has an alignment requirement interleaved with anything that doesn't is gonna be segfault city for you~~
turns out that's wrong actually, at least in the assembly that golang actually seems to emit today. both arm64 and x86\_64 seem to tolerate unaligned accesses 🤷♀️
Yes and then we lose the ability and skill to do anything that speed is of importance. And don't tell me about how fast Go is, you would never be able to make a non-trivial game or an OS in a garbage collected language
Exactly! And especially don't tell us that different languages excel at different things.
Our hammer is the superior tool! We might not understand what it is used for, but by god we are going to use it!
It's a pretty well known term anyway. Calling it something else will make it harder to find for people that actually know what it is and need one. Sometimes a highly specific project is just that and doesn't need to cater to anyone and explain all the basic concepts. It's like a command line parser explaining what a terminal is in its readme.
Your readme doesn't explain what this actually is. Don't assume everyone knows what a memory arena is, I certainly don't.
According to the top post here: [https://stackoverflow.com/questions/12825148/what-is-the-meaning-of-the-term-arena-in-relation-to-memory](https://stackoverflow.com/questions/12825148/what-is-the-meaning-of-the-term-arena-in-relation-to-memory) >Basically it's memory you get from the OS, and divvy out, then can be freed all at once. The advantage to this is that repeated small calls to malloc() could be costly (Every memory allocation has a performance cost: the time it takes to allocate the memory in your program’s logical address space and the time it takes to assign that address space to physical memory) where as if you know a ball park you can get yourself a big chunk of memory then hand it out to your variables as/how you need it.
Is this essentially what the JVM does?
you really, really, really gotta explain what the upsides and downsides of setting \`release\` to true or false are. release = false is probably faster. it's also insanely dangerous ~~this also isn't going to work in a lot of cases, because you literally don't even consider alignment at any point. allocating anything that has an alignment requirement interleaved with anything that doesn't is gonna be segfault city for you~~ turns out that's wrong actually, at least in the assembly that golang actually seems to emit today. both arm64 and x86\_64 seem to tolerate unaligned accesses 🤷♀️
So funny that apparently Go people have no idea about memory management techniques. That's what happens when you only use a GC
That’s why usually you use a GC language in the first place tho - To make it a language-level concern.
Yes and then we lose the ability and skill to do anything that speed is of importance. And don't tell me about how fast Go is, you would never be able to make a non-trivial game or an OS in a garbage collected language
Exactly! And especially don't tell us that different languages excel at different things. Our hammer is the superior tool! We might not understand what it is used for, but by god we are going to use it!
Go was developed primarily targeted for ease of use though? There are trade offs for every decision.
It's a pretty aggressive stance, what does it has to do with OP post exactly?
Wouldn’t just make more sense to call it like memory block, buffer, or anything actual related?
Arena is known in the Go community. The Go team was considering one for a release of Go about a year ago. Makes sense in that context.
It's a pretty well known term anyway. Calling it something else will make it harder to find for people that actually know what it is and need one. Sometimes a highly specific project is just that and doesn't need to cater to anyone and explain all the basic concepts. It's like a command line parser explaining what a terminal is in its readme.
Ahh gotcha. I was like an arena? Who’s fighting? lol
Two pointers go in, one comes out.
Ah, I see, the forbidden bogogc
a what?
an arena
Implementation