Hacker News
points by grg0 2 days ago | 0 comments
> 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.

[–] the-tomster 2 days ago
> 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.

[–] grg0 1 day ago
The problem is not finding limits, although that does take decent engineering for anything non-trivial. The problem is that a hard limit assumes your requests have a relatively uniform distribution of memory requirements. Otherwise, you are wasting memory. Or you have N limits instead, which just complicates the problem.

Resize: realloc invalidates pointers. If you're saying allocate more chunks and link them, that is technically no longer an arena?

Requesting virtual memory and committing lazily seems a good trade-off except on Windows, which does not allow to over-commit. Somehow I don't find that very satisfying because it relies on the OS and on the hardware to provide virtual memory support. But maybe it's just what it is.

[–] palata 1 day ago
> Two options: you either say "eh 20MB per request ought to be big enough"

"Memory is cheap" and all that? :-)

[–] MrBuddyCasino 1 day ago
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?
[–] the-tomster 1 day ago
Yup! In C you can mmap out a big anonymous region and then it will only take up actual resident space for pages you use. I'm not sure if Zig exposes this in the stdlib somewhere or if you'd just do it through libc.

If you're doing something like per-request or per-frame arenas you can clear the arena without having to reallocate the whole mapping. And depending how fancy you want to get you can mark the pages unused when you clear the arena so that the OS can reclaim them if needed.

[–] rallyroger 1 day ago
>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.

[–] grg0 1 day ago
As opposed to allocating a bunch of memory you won't need?

Allocating virtual memory up front and committing lazily might be a good trade-off, until it isn't. So I'm not actually sure and hence why I asked the question.

[–] lenkite 2 days ago
> And how do you size the arena?

All HTTP servers have a configurable maximum request size. Ex: client_max_body_size in Nginx.

[–] grg0 1 day ago
Not to take away from your point, but client_max_body_size "Sets the maximum allowed size of the client request body." That is different from how much the server/service is allowed to allocate internally to service the request.
[–] lenkite 1 day ago
Yes, my bad, replied in a hurry. Technically, the arena size will be function involving both the request body size, the response body size, along with the sizes of any intermediate results of processing.
[–] flohofwoe 2 days ago
> 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.