Hacker News Reader

Comment by IshKebab | Hacker News Reader

This came up before. TL;DR: If you use arena allocators everywhere then you won't have any memory errors!

I think the idea is a really interesting one but it would be better if he didn't wrap it in typical "I don't make mistakes" hubris. I mean I guess at least this time he has some more reason than "because I'm not stupid" but I think he's still wrong.

His technique probably reduces the chance of memory errors, but there's still nothing checking his work so he's still going to make mistakes.

The other issue he doesn't address is resource allocation. It's fine to just drop the memory of a lot of things but sometimes you have to close files, handles, etc. RAII handles that perfectly. I'm not sure about this.

I would say RAII and Rust's borrow checker are still superior but it's definitely true that they don't work well with arenas.

View on HN

> RAII handles that perfectly. I'm not sure about this.

If you're asking whether arena allocators can handle resource cleanup, then I think the answer is yes. One way to do it is to embed an intrusive linked list of destructors into your arena. So, to push an object onto the arena you would:

1. Push a function pointer (the object's destructor) and the current destructor list head onto the arena.

2. Update the destructor list head to point to the top of the arena.

3. Push the object's data onto the arena, as usual.

(source: https://www.ea.com/frostbite/news/scope-stack-allocation)

As with everything, you need to use the tool for use-cases that it was designed for.

A downside of RAII is the hidden cost of unwinding, and predictability over CPU usage. If you have a resource that supports complicated internal transformations, and memory states, then you need an equally complicated destructor that can handle all those different states. If you're not careful with this you can get CPU spikes at scope-exits.

> The other issue he doesn't address is resource allocation. It's fine to just drop the memory of a lot of things

I think there is a fundamental difference between memory and most other resources: (process's) memory is a) effectively an internal detail while other resources are externally visible (open files/sockets/etc); b) as almost a consequence, it's pretty much anonymous: when you ask for 1 MiB of memory, you ask for free, unused memory; when you ask for file "/etc/passwd" or TCP port 8080, you ask for that exact file/port.

That's why you need special destructor calls for non-memory resources, to tell the external environment that this resource is now available for others to use. Memory, on the other hand... the OS with virtual memory support will generally be able to dispense free memory until the swap file consumes all of the available disk space, and even then, it could theoretically just start dropping pieces of swap (and when a process actually tries to access the gone memory, kill it with SIGSEGV) to prolong the agony. Throw in the most rudimentary form of in-process memory reclamation, and you won't notice memory leaks until well into months of constant uptime.

So do you argue that memory is different from point of view of resourse allocation/deallocation because it is much harder to exhaust memory than file descriptors, tcp ports and such like?

No, I am arguing that memory is (roughly speaking) an internal, private resource unlike most other things (files/sockets/pipes/processes/etc), and it's intended: other resources has state outside of the process which is used to communicate with other processes, or with specific hardware (e.g. GPU) or other machines. When you close() a file/socket, it's visible outside of the process, the other side receives inotify()/epoll() message, when a (child) process exits, its status and exit code change and SIGCHLD get sent, etc. Also, anonymity: if you need a socket connected to remote example.com:443, you want it to connected to example.com:443, not to something else; when you open a file/pipe, you want it to be able to communicate with someone else (in case of file, maybe with someone else from the past/future) — note how deeply this notion of sharing is built-in into file API by considering how difficult it was to design secure API for temp files which are files one doesn't want to share with anyone. But when you free() a block of memory... nothing outside of the process gets notified, really.

And that's why automated memory management (garbage collection) is a success story while attempts to blindly apply it to other resources failed: memory is different. Freeing other resources sends a very clear message to the external environment, including other processes, which is used for IPC while freeing memory doesn't.

Yes, in the end, memory in process is implemented by (shared) physical memory but modern OSes go to ridiculous length to support the illusion that it's unlimited and private. Yes, there is shared memory mappings which I explicitly leave outside the argument: those are externally visible, nameable, and hard to manage with GC.

> I would say RAII and Rust's borrow checker are still superior but it's definitely true that they don't work well with arenas.

Note that this will definitely improve in future versions of Rust. Local allocators are an unstable feature already, and can support arena allocation.

As a C programmer who uses memory arenas quite frequently can you expand on what you know about Rust’s current or future support for such a feature?

I’d like to start writing new projects in Rust and I’d like to continue to use this approach to memory management!

You can of course use arenas in Rust just like in C. I think the parent was talking about support for using arenas as the memory for stuff like built-in containers (dynamic arrays, hash maps, etc.):

https://github.com/rust-lang/wg-allocators

Thank you! Yeah, something like bumpalo would work just fine right now but for the future this is a great interface:

https://docs.rs/bumpalo/latest/bumpalo/#nightly-rust-allocat...

  use bumpalo::Bump;
  
  let bump = Bump::new();
  
  let mut v = Vec::new_in(&bump);
  v.push(0);
  v.push(1);
  v.push(2);

Reply on news.ycombinator.com