3 ms·

While downvoting is normally a healthy expression of “this is a low-value comment, let’s bury it under more insightful comments”, which is the intended purpose.

While downvoting is normally a healthy expression of “this is a low-value comment, let’s bury it under more insightful comments”, which is the intended purpose. “Blow is right on arena-by-default” is the real point of controversy there. I think it’s obvious, but am open to contrary opinion. Carl/Yehuda/Tom profiteered off an exceptional ability to forecast language cults: maybe differ with that. But I’ve really teed up things that one can concretely disagree with: I’ve done this intentionally to deprive the arrows of any tangible meaning, as well-travelled commenters do. Dumbass under pseudonym.

zozbot234 4y ago
Rust is working on support for local allocators. They're not far from being enabled to support memory arenas (and even local, pluggable GC!) just as well, or even better than any other language in current use.
- benreesman 4y ago
  Please take my reply in the spirit of someone being replied to very unreasonably but who doesn't count you in that group: Many languages, probably most notably among them C++, have implemented varying degrees of what we might call "custom allocator policy". This is a rather extreme case of a generally over-applied maxim: "defaults matter". While it is completely possible to do a custom bump-allocator (which is the only kind of allocation on the table if you need to be fast without the help of `tcmalloc` or `jemalloc`), it's sufficiently high-friction that most write their own vector rather than doing the language lawyer thing of doing a "custom allocator". What John Blow proposes, quite reasonably if not obviously to me, is making a call-frame level arena in which all "heap" allocations are just past the last one, basically burning "reclaim opportunity" in light of the abundance of evidence that no one ever cares about memory that `jemalloc` has already done fragmentation around.

zozbot234 4y ago

Rust is working on support for local allocators. They're not far from being enabled to support memory arenas (and even local, pluggable GC!) just as well, or even better than any other language in current use.

benreesman 4y ago
Please take my reply in the spirit of someone being replied to very unreasonably but who doesn't count you in that group: Many languages, probably most notably among them C++, have implemented varying degrees of what we might call "custom allocator policy". This is a rather extreme case of a generally over-applied maxim: "defaults matter". While it is completely possible to do a custom bump-allocator (which is the only kind of allocation on the table if you need to be fast without the help of `tcmalloc` or `jemalloc`), it's sufficiently high-friction that most write their own vector rather than doing the language lawyer thing of doing a "custom allocator". What John Blow proposes, quite reasonably if not obviously to me, is making a call-frame level arena in which all "heap" allocations are just past the last one, basically burning "reclaim opportunity" in light of the abundance of evidence that no one ever cares about memory that `jemalloc` has already done fragmentation around.