It depends on the SAPI. The php-fpm approach is a pool of processes that are reused for multiple requests. Virtually all of the state visible to plain PHP code is reset between requests, however some interpreter/runtime state is kept, e.g. in-memory bytecode cache, initialized extensions, some persistent network connections, etc.

In terms of memory management, PHP has both reference counting and garbage collection. Internally, an arena per request is used[0], so leaking memory over long periods of time is fairly rare and usually limited to native extensions.

[0]: https://www.phpinternalsbook.com/php7/memory_management/zend...

It's been a while since I used PHP, but this is something controlled by the server used. If you use Apache then it used to create a new process for each request, yes.

Depends on the setup, but even when it doesn't, it mallocs a huge chunk of memory at the start, lets the script run, allocate away and never free anything. Then, when the script is done, it frees the whole chunk in one fell swoop.

So for some definition of “process” it holds regardless - it’s just not always a real OS process.

They added GC at some point to allow scripts to run longer (eg for websocket servers) but even then last I checked you had to manually enable it.

Depending on the configuration, yes.

It used to be a quite common approach in UNIX server programming.