The idea here is that the webserver forks & execs a new process for every request, allocates a bunch of pages, and then runs to completion, at which point the process finishes and the memory is returned to the OS. It's essentially using the OS as an arena, where you can allocate memory at will just by bumping a pointer and then the whole thing is freed at once at the end of the request.

It's not an insane idea - CGI worked exactly like this, as do most command-line shells. And the overhead is often less than most people expect, since most pages are COWed on fork() and the files it touches will likely be in the filesystem cache. Still, I think people found that the overhead from process creation (and in particular, keeping all those processes around & task-switching them while they make DB/network/filesystem calls) was greater than that from GC, and so most frameworks - PHP included, these days! - use a more lightweight mechanism.

Yes, I know what the idea is. I highly suspect it won't be practical due to the reasons given in my other reply. We tried this with JavaScript in a very similar domain and the memory usage was unacceptable.

Sorry, but GP is right here... you really don't need GC if the entire process ends and the memory is completely freed at the end of the request.

Not that I feel cgi is the most efficient way to handle requests... but not needing the complexity of GC could be one advantage of that approach...

It may seem that way at first, but space leaks during individual requests are way too easy otherwise. Think about something as simple as, say, parsing Mustache templates. The parser is probably internally making lots of little substrings to record the names of directives as it comes to them. You would think that this is O(1) in space, since you only need one (or a small number) of strings at a time, but without a GC the space requirements balloon to O(size of input). Being able to dump the memory at the end of a request doesn't help you if you keep blowing out your cache during each one.

I speak from experience: there have been many attempts to mandatorily delay collection until the end of the event loop in browsers, to achieve greater responsiveness. It has always failed. You can add heuristics to try to preferentially collect at the end of the event loop, but you really need to be able to GC anytime.

I'm not completely disagreeing... I've worked on pipeline transformers in node where I exposed gc and ran it after each item in the pipeline was done. It would grow insane without it... likewise I can see that if you're transforming a lot of records for delivery in PHP it could bloat as well.

However, if you're handling requests well within a given memory threshold, it isn't always something you should worry about until it becomes a problem. In which case, you'll probably want to look at something like go, rust, erlang or others to handle improvements, or break off heavy parts into sub/micro-services.

for the specific case of templating: you wouldn't want to parse mustache in production, and use a pre-compiled template.