Item — HN Reader

I know of a lot of people trying to do "arena" GC in Rust using integer indices. I think that's an excellent approach, but it does mean you have to pass in the arena as a resource to every single function which produces an allocation. This isn't even necessarily a bad thing - the net result is a lot like Zig's allocator API.

I know there's a nontrivial overhead to using index-based references, especially since CPUs can't easily predict load operations. This gives me an idea: create a CPU architecture where pointers are actually (object, offset) tuples, enabling better on-metal performance with index-based references. I've neither the time, money, expertise, nor energy to implement such a thing, but it would be really cool if it existed - maybe CHERI is a close approximation, though I haven't looked very closely at it.

1 comments

> it does mean you have to pass in the arena as a resource to every single function which produces an allocation

Implicit arguments! I'm more and more convinced that this form of controlled dynamic scoping dynamic scoping should be embraced by more languages.

> create a CPU architecture where pointers are actually (object, offset) tuples

Segments might yet see a renaissance (and CHERI might be indeed be a form of it).

Yes, the obvious way to do this is have the compiler add a context parameter to every function that allocates memory or dereferences a pointer (semantically). To run the program, the main function ala c initializes the context and passes it in to the actual main program implementation. When the program finishes, all the memory can just be released in bulk in the wrapper main that initialized the context.

This is actually a serious proposal for the Rust language, it's called contexts and capabilities

Here's a blog post from 2021 https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa...

This isn't implemented yet, and the proposal never matured into a proper RFC, but there's high interest for some solution along those lines

And just a note, this is called Reader monad in Haskell

In other words, receiving an implicit parameter is a kind of effect. So another way to provide this feature is to have a full blown effect system (which is much more general and is probably overkill, but there's also some interest for that)

How is that much different than just using malloc and then letting the OS clean up when the process exits?

By having implicit arguments, a framework can decide when to override the implictness and be explicit to use a different arena when needed.

Also, many process like servers are long lived, so the OS clean up strategy does not work for them, and they are exactly where you want some strategy for memory allocation like arenas to prevent memory fragmentation.

> Implicit arguments! I'm more and more convinced that this form of controlled dynamic scoping dynamic scoping should be embraced by more languages.

This might be an odd comment, but this is sorta similar to React's Context mechanism. For what it's worth, it makes a lot of things easier but it can definitely also add a lot of surface area for complexity. Although it's certainly better than relying on globals all over the place.