Svantaggi della gestione della memoria basata su ambito

Mi piace molto la gestione della memoria basata sull'ambito (SBMM) o RAII , in quanto viene più comunemente (confusamente?) Indicato dalla comunità C ++. Per quanto ne so, ad eccezione di C ++ (e C), non esiste nessun altro linguaggio corrente oggi in uso che rende SBMM / RAII il loro principale meccanismo di gestione della memoria, e preferiscono invece usare Garbage Collection (GC).

Lo trovo piuttosto confuso, da allora

1. SBMM rende i programmi più deterministici (puoi dire esattamente quando un oggetto viene distrutto);
2. nei linguaggi che usano GC devi spesso fare una gestione manuale delle risorse (vedi la chiusura dei file in Java, per esempio), che in parte vanifica lo scopo di GC ed è anche soggetto a errori;
3. la memoria heap può anche (molto elegantemente, imo) essere legata all'ambito (vedi std::shared_ptrin C ++).

Perché SBMM non è più ampiamente utilizzato? Quali sono i suoi svantaggi?

Cominciamo postulando che la memoria è di gran lunga (decine, centinaia o addirittura migliaia di volte) più comune di tutte le altre risorse combinate. Ogni singola variabile, oggetto, membro oggetto necessita di memoria allocata e liberata in seguito. Per ogni file che apri, crei dozzine a milioni di oggetti per archiviare i dati estratti dal file. Ogni flusso TCP si accompagna a un numero illimitato di stringhe di byte temporanee create per essere scritte nel flusso. Siamo sulla stessa pagina qui? Grande.

Perché RAII funzioni (anche se hai puntatori intelligenti già pronti per ogni caso d'uso sotto il sole), devi avere la proprietà giusta. Devi analizzare chi dovrebbe possedere questo o quell'oggetto, chi non dovrebbe, e quando la proprietà dovrebbe essere trasferita da A a B. Certo, potresti usare la proprietà condivisa per tutto , ma poi emuleresti un GC tramite puntatori intelligenti. A quel punto diventa molto più facile e veloce costruire il GC nella lingua.

La garbage collection ti libera da questa preoccupazione per la risorsa di gran lunga più comunemente usata, la memoria. Certo, devi ancora prendere la stessa decisione per altre risorse, ma quelle sono molto meno comuni (vedi sopra) e anche la proprietà complicata (ad esempio condivisa) è meno comune. Il carico mentale è ridotto in modo significativo.

Ora, dai un nome ad alcuni aspetti negativi nel rendere tutti i valori raccolti. Tuttavia, l'integrazione di GC di sicurezza della memoria e tipi di valore con RAII in una lingua è estremamente difficile, quindi forse è meglio mimare questi compromessi con altri mezzi?

La perdita di determinismo si rivela in realtà non così grave in pratica, poiché influisce solo sulla durata deterministica dell'oggetto . Come descritto nel paragrafo successivo, la maggior parte delle risorse (a parte la memoria, che è abbondante e può essere riciclata piuttosto pigramente) non è destinata alla durata dell'oggetto in queste lingue. Ci sono alcuni altri casi d'uso, ma sono rari nella mia esperienza.

Il tuo secondo punto, la gestione manuale delle risorse, è oggi affrontato tramite un'istruzione che esegue la pulizia basata sull'ambito, ma non associa questa pulizia al tempo di vita dell'oggetto (quindi non interagisce con il GC e la sicurezza della memoria). Questo è usingin C #, within Python, try-con-risorse nelle recenti versioni di Java.

RAII segue anche la gestione automatica della memoria per il conteggio dei riferimenti, ad esempio utilizzata da Perl. Sebbene il conteggio dei riferimenti sia facile da implementare, deterministico e abbastanza performante, non può gestire riferimenti circolari (causano una perdita), motivo per cui non è comunemente usato.

Le lingue raccolte con immondizia non possono usare direttamente RAII, ma spesso offrono sintassi con un effetto equivalente. In Java, abbiamo l'istruzione try-with-ressource

try (BufferedReader br = new BufferedReader(new FileReader(path))) { ... }

che chiama automaticamente .close()la risorsa all'uscita del blocco. C # ha l' IDisposableinterfaccia, che consente .Dispose()di essere chiamato quando si lascia using (...) { ... }un'istruzione. Python ha la withdichiarazione:

with open(filename) as f:
    ...

che funziona in modo simile. In una svolta interessante, il metodo di apertura del file di Ruby ottiene un callback. Dopo l'esecuzione del callback, il file viene chiuso.

File.open(name, mode) do |f|
    ...
end

Penso che Node.js usi la stessa strategia.

A mio avviso, il vantaggio più convincente della raccolta dei rifiuti è che consente la componibilità . La correttezza della gestione della memoria è una proprietà locale nell'ambiente di raccolta rifiuti. È possibile esaminare ciascuna parte separatamente e determinare se può perdere memoria. Combina un numero qualsiasi di parti corrette per la memoria e rimangono corrette.

Quando si fa affidamento sul conteggio dei riferimenti si perde quella proprietà. Se l'applicazione può perdere la memoria diventa una proprietà globale dell'intera applicazione con il conteggio dei riferimenti. Ogni nuova interazione tra le parti ha la possibilità di utilizzare la proprietà errata e interrompere la gestione della memoria.

Ha un effetto molto visibile sulla progettazione di programmi nelle diverse lingue. I programmi in linguaggi GC tendono ad essere un po 'più minuscoli di oggetti con molte interazioni, mentre in linguaggi senza GC si tende a preferire parti strutturate con interazioni strettamente controllate e limitate tra loro.

Le chiusure sono una caratteristica essenziale di quasi tutte le lingue moderne. Sono molto facili da implementare con GC e molto difficili (anche se non impossibili) da ottenere con RAII, poiché una delle loro caratteristiche principali è che ti permettono di astrarre nel corso della vita delle tue variabili!

Il C ++ li ha acquisiti solo 40 anni dopo che lo hanno fatto tutti gli altri, e ci sono voluti un sacco di duro lavoro da parte di molte persone intelligenti per farli bene. Al contrario, molti linguaggi di scripting progettati e implementati da persone con zero conoscenze nella progettazione e implementazione dei linguaggi di programmazione li hanno.

1. SBMM rende i programmi più deterministici (puoi dire esattamente quando un oggetto viene distrutto);

Per la maggior parte dei programmatori il sistema operativo non è deterministico, il loro allocatore di memoria non è deterministico e la maggior parte dei programmi che scrivono sono concorrenti e, quindi, intrinsecamente non deterministici. L'aggiunta del vincolo che un distruttore viene chiamato esattamente alla fine dell'ambito piuttosto che leggermente prima o leggermente dopo non è un vantaggio pratico significativo per la stragrande maggioranza dei programmatori.

2. nei linguaggi che usano GC devi spesso fare una gestione manuale delle risorse (vedi la chiusura dei file in Java, per esempio), che in parte vanifica lo scopo di GC ed è anche soggetto a errori;

Vedi usingin C # e usein F #.

3. la memoria heap può anche (molto elegantemente, imo) essere legata all'ambito (vedi std :: shared_ptr in C ++).

In altre parole, potresti prendere l'heap che è una soluzione di uso generale e cambiarlo per funzionare solo in un caso specifico che sta seriamente limitando. Questo è vero, certo, ma inutile.

Perché SBMM non è più ampiamente utilizzato? Quali sono i suoi svantaggi?

SBMM limita ciò che puoi fare:

1. SBMM crea il problema funarg verso l' alto con chiusure lessicali di prima classe, motivo per cui le chiusure sono popolari e facili da usare in linguaggi come C # ma rare e complicate in C ++. Si noti che esiste una tendenza generale verso l'uso di costrutti funzionali nella programmazione.

2. SBMM richiede i distruttori e impediscono le chiamate in coda aggiungendo più lavoro da fare prima che una funzione possa tornare. Le chiamate di coda sono utili per macchine a stati estensibili e sono fornite da cose come .NET.

3. Alcune strutture di dati e algoritmi sono notoriamente difficili da implementare usando SBMM. Praticamente ovunque quei cicli si verificano naturalmente. In particolare algoritmi grafici. Alla fine finisci per scrivere il tuo GC.

4. La programmazione concorrente è più difficile perché il flusso di controllo e, quindi, la durata degli oggetti sono intrinsecamente non deterministici qui. Le soluzioni pratiche nei sistemi di trasmissione dei messaggi tendono ad essere una copia profonda dei messaggi e l'uso di una durata eccessivamente lunga.

5. SBMM mantiene gli oggetti in vita fino alla fine del loro ambito nel codice sorgente, che è spesso più lungo del necessario e può essere molto più lungo del necessario. Ciò aumenta la quantità di immondizia galleggiante (oggetti non raggiungibili in attesa di essere riciclati). Al contrario, il tracciamento della garbage collection tende a liberare oggetti subito dopo la scomparsa dell'ultimo riferimento ad essi, che può essere molto prima. Vedi Miti sulla gestione della memoria: prontezza .

SBMM è così limitante che i programmatori hanno bisogno di una via di fuga per situazioni in cui non è possibile nidificare le vite. In C ++, shared_ptroffre una via di fuga ma può essere ~ 10 volte più lenta della traccia della garbage collection . Quindi usare SBMM invece di GC metterebbe la maggior parte delle persone a piede sbagliato la maggior parte delle volte. Ciò non significa, tuttavia, che sia inutile. SBMM ha ancora valore nel contesto dei sistemi e della programmazione integrata in cui le risorse sono limitate.

FWIW potresti voler dare un'occhiata a Forth e Ada e leggere il lavoro di Nicolas Wirth.

Guardando un indice di popolarità come TIOBE (che è discutibile, ovviamente, ma suppongo che per il tuo tipo di domanda sia giusto usarlo), vedi prima che circa il 50% dei primi 20 sono "linguaggi di scripting" o "dialetti SQL ", dove la" facilità d'uso "e i mezzi di astrazione hanno un'importanza molto maggiore del comportamento deterministico. Dalle restanti lingue "compilate", ci sono circa il 50% delle lingue con SBMM e ~ 50% senza. Quindi, quando togli i linguaggi di scripting dal tuo calcolo, direi che la tua ipotesi è sbagliata, tra i linguaggi compilati quelli con SBMM sono popolari come quelli senza.

Un grande vantaggio di un sistema GC che nessuno ha ancora menzionato è che un riferimento in un sistema GC è garantito per mantenere la sua identità finché esiste . Se si chiama IDisposable.Dispose(.NET) o AutoCloseable.Close(Java) su un oggetto mentre esistono copie del riferimento, tali copie continueranno a fare riferimento allo stesso oggetto. L'oggetto non sarà più utile per nulla, ma i tentativi di utilizzo avranno un comportamento prevedibile controllato dall'oggetto stesso. Al contrario, in C ++, se il codice chiama deleteun oggetto e successivamente tenta di usarlo, l'intero stato del sistema diventa totalmente indefinito.

Un'altra cosa importante da notare è che la gestione della memoria basata sull'ambito funziona molto bene per oggetti con proprietà chiaramente definite. Funziona molto meno bene, e talvolta addirittura male, con oggetti che non hanno una proprietà definita. In generale, gli oggetti mutabili dovrebbero avere proprietari, mentre gli oggetti immutabili non ne hanno bisogno, ma c'è una ruga: è molto comune che il codice usi un'istanza di tipi mutabili per contenere dati immutabili, garantendo che nessun riferimento sarà esposto a codice che potrebbe mutare l'istanza. In tale scenario, le istanze della classe mutabile potrebbero essere condivise tra più oggetti immutabili e quindi non avere una chiara proprietà.

Prima di tutto, è molto importante rendersi conto che equiparare RAII a SBMM. o anche a SBRM. Una delle qualità più essenziali (e meno conosciute o meno apprezzate) di RAII è il fatto che rende "essere una risorsa" una proprietà che NON è transitiva alla composizione.

Il seguente post sul blog discute questo importante aspetto di RAII e lo contrappone all'ampliamento delle risorse nei linguaggi GCed che usano GC non deterministico.

http://minorfs.wordpress.com/2011/04/29/why-garbage-collection-is-anti-productive/

È importante notare che mentre RAII viene utilizzato principalmente in C ++, Python (finalmente la versione non basata su VM) ha distruttori e GC deterministici che consentono l'utilizzo di RAII insieme a GC. Meglio di entrambi i mondi se fosse.