Comment by grg0
10 hours ago
> Now all of your allocations during that connection are guaranteed to be freed instead of having to keep track of them individually
And how do you size the arena?
> keep track of them individually
I think this is an exaggeration of the problem. This is what RAII semantics in C++ are for.
> avoiding that kind of invisible code
The invisible code is traded for defer statements right after initialization that are obvious and therefore mostly just noise, and also a problem if you forget to call them. This isn't an issue with RAII. I get the point of not wanting invisible code, but defers don't seem much of an improvement either. A trade-off at best.
>And how do you size the arena?
Should you allow an http-server to allocate unbounded request sizes? Seems like it would lead to an easy denial of service.
> And how do you size the arena?
Two options: you either say "eh 20MB per request ought to be big enough" and resize it later if you need to. Or you take time to figure out reasonable limits in terms of whatever domain you're dealing with, and return descriptive errors when those limits are exceeded. Maybe you're saying your service supports up to N HTTP headers and M query parameters in the URL and so on. For almost anything there's a limit you can place that's reasonable. Having no limits at all just means the limit is when you run out of memory / disk / whatever.
If you like RAII and C++ just use that though, Zig is an alternative not an upgrade, imo.
Can arenas be made to use no actual memory unless it is being used, so the virtual memory subsystem only allocates pages when written to?
> And how do you size the arena?
All HTTP servers have a configurable maximum request size. Ex: client_max_body_size in Nginx.
> This is what RAII semantics in C++ are for.
...which typically has more overhead than a good GC though and much more overhead than using arenas for lifetime management.