They could probably learn one or two things on how Java and .NET do arenas, just saying.
Not sure about .NET, but Java doesn't have arenas..
It’s this simple in .NET
ArrayPoolGolang's big miss on memory arenas
81–90 of 157 posts
Re: Golang's big miss on memory arenas
#82Earlier quoted context omitted.
Newbies want a compelling catchphrase: C: So powerful you can shoot your foot off! Rust: Now that you've shot your foot off, let's not do that a second time. Javascript: It runs on the server and in the browser . Typescript: It runs on the server and in the browser, now with types! In contrast, PHP: Not sure if I want to be a templating language or general-purpose programming language.
PHP is: see your changes by refreshing your browser. At least that was it’s initial appeal.
Not the ability to mix SQL injection vulnerabilities into the middle of your HTML?
Regardless, you’re thinking of Perl/CGI. PHP did attract the Perl crowd away from Perl, but it wasn’t for that reason. That was already the norm.
Re: Golang's big miss on memory arenas
#83Re: Golang's big miss on memory arenas
#84What's the downside of having one API to pre-allocate memory to be used by the GC, and a second API to suspend/resume GC operations? When you run out of pre-allocated memory, it will resume GC operations automatically.
I'm naively thinking, the performance bottleneck is not with tracking allocations but constantly freeing them and then reallocating. Let the GC track allocations, but prevent it from doing anything else so long as it is under the pre-allocated memory limit for the process. When resumed, it will free unreferenced memory. That way, the program can suspend GC before a performance sensitive block and resume it afterwards. API's don't need to change, because the change at all that way.
Re: Golang's big miss on memory arenas
#85Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…
I personally loved using Go 8 years ago. When I built a proof of concept for a new project in both Go and Rust, it became clear that Rust would provide the semantics I’m looking for out of the box. Less fighting with the garbage collector or rolling out my own memory management solution. If I’m doing that with a lot of ugly code - I might as well use idiomatic Zig with arenas. This is exactly the point the author tri…
> Go just isn’t the tool we thought for some jobs
Go made it explicitly clear when it was released that it was designed to be a language that felt dynamically-typed, but with performance closer to statically-typed languages, for only the particular niche of developing network servers.
Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on?
One thing that has changed in the meantime is that many actually dynamically-typed languages have also figured out how to perform more like a statically-typed language. That might prompt you to just use one of those dynamically-typed languages instead, but I'm not sure that gives any reason to see Go as being less than it was before. It still fulfills the expectation of having performance more like a statically-typed language.
Re: Golang's big miss on memory arenas
#86There's a bunch of activity ongoing to make things better for memory allocation/collection in Go. GreenTeaGC is one that has already landed, but there are others like the RuntimeFree experiment that aims at progressively reduce the amount of garbage generated by enabling safe reuse of heap allocations, as well as other plans to move more allocations to the stack.
Somehow concluding that "By killing Memory Arenas, Go effectively capped its performance ceiling" seems quite misguided.
Re: Golang's big miss on memory arenas
#87Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…
> If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type.
A word of caution. If you do this and then you store pointers into that slice, the GC will likely not see them (as if you were just storing them as `uintptr`s)
Re: Golang's big miss on memory arenas
#88Earlier quoted context omitted.
Two big issues in Golang are that you can't actually build an arena allocator that can be used for multiple types in a natural way. The other is that almost no library is written in such a way that buffer re-use is possible (looking at you, typical kafka clients that throw off a buffer of garbage per message and protobuf). The latter could be fixed if people paid more attention to returning buffers to the caller.
You totally can build it using unsafe and generics. I’ve done it with mmap-backed byte slices for arbitrary object storage.
With a number of caveats. You cannot reimplement arenas as the experiment did without special hooks into the runtime. https://github.com/golang/go/blob/master/src/arena/arena.go
Re: Golang's big miss on memory arenas
#89> One concern was that Arenas introduced “Use-After-Free” bugs, a classic C++ problem where you access memory after the arena has been cleared, causing a crash.
In Rust, can the lifetime of objects be tied to that of the arena to prevent this?
Asking as a C/C++ programmer with not much Rust experience.
Re: Golang's big miss on memory arenas
#90> One concern was that Arenas introduced “Use-After-Free” bugs, a classic C++ problem where you access memory after the arena has been cleared, causing a crash. In Rust, can the lifetime of objects be tied to that of the arena to prevent this? Asking as a C/C++ programmer with not much Rust experience.
Yes, or rather, the lifetime of references to the contained objects can be tied to the lifetime of references to the arena. E.g., the bumpalo crate [0] has two relevant methods, Bump::alloc(), which puts a value into the arena and gives you back a reference, and Bump::reset(), which erases everything from the arena.
But Bump::reset() takes a &mut self, while Bump::alloc() takes a &self reference and gives back a &mut T reference of the same lifetime. In Rust, &mut references are exclusive, so creating one for Bump::reset() ends the lifetime of all the old &self references, and thus all the old &mut T references you obtained from Bump::alloc(). Ergo, once you call Bump::reset(), none of the contained objects are accessible anymore. The blogpost at [2] gives a few other crates with this same &self -> &mut T pattern.
Meanwhile, some crates such as slab [1] effectively give you a numeric key or token to access objects, and crates differ in whether they have protections to guarantee that keys are unique even if objects are removed. All UAF protection must occur at runtime.
[0] https://docs.rs/bumpalo/3.19.0/bumpalo/struct.Bump.html