Allocatore di memoria basato su richiesta

Questa idea non è nuova:

• CGI creerà un'istanza completamente nuova dell'app Web per ogni singola richiesta. Al termine della richiesta, il processo viene terminato dal sistema operativo e la memoria viene recuperata come qualsiasi altro programma.
• PHP nella sua modalità di operazione più semplice farà lo stesso (comunque i moderni framework web PHP non lo faranno).
• Il modello standard di Erlang consiste nell'utilizzare un attore per richiesta. In Erlang, ogni attore ha il proprio mucchio di spazzatura privata. Quindi, se la richiesta è molto long-running, il garbage collector raccoglierà solo oggetti morti in quella singola richiesta, ma più probabilmente, la richiesta è così breve che il garbage collector non avrà mai bisogno di funzionare e la memoria sarà solo recuperato dalla VM di Erlang quando l'attore finisce.

CGI e la modalità per richiesta di PHP sono stati abbandonati perché i processi sono spesso molto costosi. Ma questo è un problema con l'implementazione dei processi, non un problema inerente al modello in quanto tale: un processo di Erlang, ad esempio, pesa solo 200 byte e può essere avviato e distrutto in poche istruzioni.

Volevo anche sottolineare che "causare ritardi indesiderati del GC" non è tanto un problema di alcune lingue, quanto piuttosto alcune implementazioni di Garbage Collector. Ad esempio, il garbage collector Metronome disponibile come opzione a pagamento per J9 di IBM JVM ha tempi di pausa massimi configurabili fino a 1 ms. Il C4 (Collector di compattazione simultanea continua) di Azul non ha tempi di pausa notevoli poiché è completamente concurrent: non solo le sue fasi interne possono essere eseguite contemporaneamente, ma possono anche essere eseguite contemporaneamente al codice utente.

Il modello di allocazione di un gruppo e solo la pulizia alla fine è in realtà abbastanza comune. Sebbene l'obiettivo principale sia evitare il costo dell'assegnazione stessa in molti casi. Che il modello di allocazione consenta un ingombro è spesso una felice coincidenza.

Uno degli svantaggi è che la memoria allocata potrebbe diventare molto grande anche se la maggior parte della memoria in essa contenuta è morta, ad esempio riallocando di frequente. Anche se ciò dovrebbe essere risolvibile, è più intelligente sulle allocazioni, come riservare spazio sufficiente per evitare di dover eseguire un realloc.

Un altro svantaggio è che i distruttori RAII diventeranno difficili. Distruggere una struttura spinta su questa piscina proverebbe a distruggere altri oggetti sulla piscina che potrebbero causare una doppia distruzione. Una soluzione per questo sarebbe di non eseguire i distruttori per gli oggetti inseriti nella memoria allocata, ma invece di collegare la pulizia delle loro risorse esterne (connessioni di database, file, ...) a request così quando la richiesta è finita può ripulire le sue risorse che non sono già state.

Forse l'avvertimento principale con questo è comunque quando si desidera allocare memoria che rimane attiva dopo che la richiesta è stata eseguita come per una cache di sessione o il risultato di un grande calcolo che utilizza un allocatore di questo tipo.