3 ms·

I don't see why a language would need special support for arenas, unless it is GCed. It's a simpler alloction model than malloc, and C++ doesn't really have bui

I don't see why a language would need special support for arenas, unless it is GCed. It's a simpler alloction model than malloc, and C++ doesn't really have builtin support for malloc either, it just calls free() in a bunch of destructors in the STL.

benreesman 3y ago
In fairness std::allocator has always been a wreck, and in fairness RAII let’s you do a fairly low friction arena: but you run to the same set of problems that the C folks have with things as common as doubly linked lists. There are plenty of good ones, but every project has a different one. Jai just throws you a bump-allocated heap arena with a (tunable) default bigger than 8MB that you can hit with idiomatic syntax in every basic block. None of this is impossible in C or C++ or Rust or Java: but idiomatic defaults and notation matter. Most per-method allocations should be pointer bumped in an arena (we’re already paying for page tables and a TLB, might as well get our money’s worth), and the languages just don’t encourage it.
- menaerus 3y ago
  > In fairness std::allocator has always been a wreck std::allocator is just fine - it's no more and no less than a wrapper around malloc/free and that's what it really only needs to be. If you need a different allocation scheme that your workload is going to benefit from: (1) you first need to come up with it by finding out what scheme is going to benefit you, (2) you then implement it through a custom allocator. > Most per-method allocations should be pointer bumped in an arena ... and the languages just don’t encourage it. System malloc implementation will do that by themselves whenever they see fit. And this is not the programming language problem to begin with at all.
pjmlp 3y ago
Pascal in its various variants had support for arenas already into the language. C++ new isn't required to call malloc()/free() per ISO C++, underlying OS APIs can be called instead, there are the whole allocator infrastrcture, and placement new as well.

benreesman 3y ago

In fairness std::allocator has always been a wreck, and in fairness RAII let’s you do a fairly low friction arena: but you run to the same set of problems that the C folks have with things as common as doubly linked lists. There are plenty of good ones, but every project has a different one. Jai just throws you a bump-allocated heap arena with a (tunable) default bigger than 8MB that you can hit with idiomatic syntax in every basic block. None of this is impossible in C or C++ or Rust or Java: but idiomatic defaults and notation matter. Most per-method allocations should be pointer bumped in an arena (we’re already paying for page tables and a TLB, might as well get our money’s worth), and the languages just don’t encourage it.

menaerus 3y ago
> In fairness std::allocator has always been a wreck std::allocator is just fine - it's no more and no less than a wrapper around malloc/free and that's what it really only needs to be. If you need a different allocation scheme that your workload is going to benefit from: (1) you first need to come up with it by finding out what scheme is going to benefit you, (2) you then implement it through a custom allocator. > Most per-method allocations should be pointer bumped in an arena ... and the languages just don’t encourage it. System malloc implementation will do that by themselves whenever they see fit. And this is not the programming language problem to begin with at all.

pjmlp 3y ago

Pascal in its various variants had support for arenas already into the language. C++ new isn't required to call malloc()/free() per ISO C++, underlying OS APIs can be called instead, there are the whole allocator infrastrcture, and placement new as well.