Am I the only one who finds it sad when people flagellate themselves before bringing up the topic of C programming?
Untangling Lifetimes: The Arena Allocator
11–20 of 94 posts
Re: Untangling Lifetimes: The Arena Allocator
#12Is there an equivalent insight but instead of C it is web dev and instead of Malloc it is JQuery and GC being React? In other words is there an elegant way to build a complex SPA with vanilla JS
> In other words is there an elegant way to build a complex SPA with vanilla JS
Svelte and SolidJS. They add a compilation step that turns fully abstracted SPA framework code into vanilla JS doing efficient DOM operations. If you wanted something even closer to the speed of C, you could imagine a framework using WASM to generate arbitrarily complex raw HTML and add it to the DOM in a single operation. This would basically match the speed of plain old SSR, with only the limited overhead of running WASM on the client.
Re: Untangling Lifetimes: The Arena Allocator
#13Anyone read it all and can tldr any interesting insights?
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…
> 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.
Re: Untangling Lifetimes: The Arena Allocator
#14> the implementation simply reserves the address range in your virtual address space (e.g. by using VirtualAlloc on Windows).
Does anyone know what would be the alternatives to VirtualAlloc on other platforms?
Re: Untangling Lifetimes: The Arena Allocator
#15> the implementation simply reserves the address range in your virtual address space (e.g. by using VirtualAlloc on Windows). Does anyone know what would be the alternatives to VirtualAlloc on other platforms?
On Linux and other UNIX-like operating systems, that would be mmap with the MAP_ANONYMOUS flag.
Re: Untangling Lifetimes: The Arena Allocator
#16> the implementation simply reserves the address range in your virtual address space (e.g. by using VirtualAlloc on Windows). Does anyone know what would be the alternatives to VirtualAlloc on other platforms?
On Linux and other UNIX-like operating systems, that would be mmap with the MAP_ANONYMOUS flag.
[deleted]
Re: Untangling Lifetimes: The Arena Allocator
#17Earlier quoted context omitted.
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…
> 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 as…
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?
Re: Untangling Lifetimes: The Arena Allocator
#18The author should take another look at RIIA. The first big difference is that it works with non-memory resources too, for example open/close for files. The second is that it makes heap allocated data feel a lot like stack allocated data, since the resources are ultimately owned by variables on the stack. With “move semantics” resources can be passed as arguments and returned by functions too, so the example of lifeti…
It's a C++ myth that files and memory are the same problem, in reality files are an easier problem, cf java.
Re: Untangling Lifetimes: The Arena Allocator
#19Anyone read it all and can tldr any interesting insights?
It's a good technical explanation of how arena allocation (a useful and easily googleable memory management technique) works in practice, in C, along with: * A lot of arguing that all other ways of dealing with the problem (garbage collectors, RAII, etc) are misguided and make for worse programs. This is a lot more controversial than "arena allocation is useful" but I have some sympathy for it. He's not alone in thin…
He talks about gamedev, and arena allocators are common sense in gamedev. It's more like introduction of a gamedev concept to business programming.
Also:
>Learning how to work with arenas entirely revolutionized my experience with writing code in C.
But, right, arena allocator is a tool, not a solution, you still have to invent a solution every time, it's still manual memory management, just an easier one.
Re: Untangling Lifetimes: The Arena Allocator
#20Anyone read it all and can tldr any interesting insights?
Arena allocator lets you group allocations greatly reducing difficulty of correct manual memory management. As a bonus icache is used more economically too.