Garbage collection: differenze tra le versioni

Versione delle 13:15, 12 ott 2023

Versione delle 13:17, 12 ott 2023

Riga 9:

# Recuperare le [[risorsa informatica|risorse]] utilizzate da questi oggetti.

Attuando il processo di ''garbage collection'' l'ambiente nel quale viene eseguito il programma gestisce la memoria automaticamente, liberando il [[programmatore]] dalla necessità di prevedere quando rilasciare le risorse utilizzate da un oggetto non più necessario all'[[elaborazione dati|elaborazione]]. Tale modalità automatica migliora la stabilità dei programmi in quanto consente di evitare quella classe di [[bug]] connessi all'utilizzo di puntatori alle varie aree di memoria già liberate in passato.<ref group="N">Tecnicamente chiamato il problema dei '[[dangling pointer]]s'.</ref>

Alcuni [[linguaggio di programmazione|linguaggi di programmazione]], come [[Java (linguaggio di programmazione)|Java]], [[Python]] e [[C sharp|C#]] ([[.NET]]), hanno un sistema di ''garbage collection'' integrato direttamente nell'ambiente di esecuzione, mentre per altri linguaggi, come il [[C (linguaggio)|C]] e il [[C++]], la sua eventuale implementazione è a carico del programmatore. Tuttavia molti linguaggi di programmazione utilizzano una combinazione dei due approcci, come [[Ada (linguaggio)|Ada]], [[Modula-3]] e [[Common Language Infrastructure|CLI]], consentono all'utente di eliminare manualmente gli oggetti, o, volendo velocizzare il processo, addirittura disattivare la gestione automatica del sistema GC. La garbage collection è quasi sempre strettamente integrata con l'[[Allocazione dinamica della memoria|allocazione di memoria]].

Riga 19:

* ''[[Dangling pointer|Dangling pointers]]'': persistenza nel programma di puntatori che si riferiscono ad aree di memoria che contenevano oggetti, ormai delocate. Utilizzare tali aree di memoria delocate può, nel migliore dei casi, provocare un errore fatale dell'applicazione, ma si possono manifestare altri problemi anche a distanza di tempo dalla effettiva delocazione. La risoluzione di questi problemi può essere molto difficoltosa.

* ''Doppia deallocazione'': il programma tenta di liberare nuovamente una zona di memoria già rilasciata.

* ''Alcuni tipi di [[memory leak]]s'': il programma perde traccia di alcune aree di memoria allocate<ref group="N">Ad esempio nel caso in cui il puntatore ad esse viene modificato.</ref>, perdendo la possibilità di deallocarle nel momento in cui non servono più. Questo tipo di problema può accumularsi nel corso dell'esecuzione del programma, portando, nel corso del tempo, all'esaurimento della memoria disponibile.

La maggior parte degli errori di programmazione nei linguaggi che non prevedono la garbage collection, o quando la stessa venga volontariamente disattivata, rientrano nei casi sopra descritti.

Riga 65:

=== Algoritmo di base ===

I ''Tracing collector'' sono algoritmi dedicati, in quanto in grado di tracciare il set di lavoro della memoria, effettuando ciclicamente la raccolta degli oggetti non più necessari. Un ciclo viene avviato quando il Garbage Collector stabilisce di avere la necessità di recuperare memoria; ciò accade più frequentemente quando il sistema è in memoria bassa. Il metodo originale prevede un mark-and-sweep<ref group="N">Trad.Ing.:"''Marca e butta via''"</ref> in cui il set di memoria viene più volte analizzato.

==== Naïve mark-and-sweep ====

Nel ''mark-and-sweep'' ogni oggetto in memoria possiede un [[flag]], in genere è sufficiente un [[bit]], riservato esclusivamente per l'utilizzo del Garbage Collector. Quando l'oggetto viene creato, il [[flag]] viene posto in stato, ''flag clear''<ref name=":0" group="N">Trad.Ing.:"''Non in uso''"</ref>.

Durante la prima fase, o fase di Mark, del ciclo di Garbage Collection, viene scansionato l'intero set di [[Root (informatica)|root]], ponendo ogni oggetto in stato di ''flag set.''<ref name=":1" group="N">Trad.Ing.:"''In Uso''"</ref> Tutti gli oggetti accessibili dalla radice del set sono anch'essi contrassegnati come in stato di ''flag set''.<ref name=":1" group="N" />

Nella seconda fase, o fase di Sweep, ogni oggetto in memoria viene ancora una volta esaminato; quelli che hanno ancora il ''flag clear''<ref name=":0" group="N" /> non sono raggiungibili da nessun programma o dato, e la loro memoria viene quindi liberata. Per gli oggetti che sono marcati flag set, il flag viene posto in stato ''flag clear''<ref name=":0" group="N" />, preparandoli per il prossimo ciclo di Garbage Collection.

Questo metodo ha diversi svantaggi, per esempio, l'intero sistema viene sospeso durante la Garbage Collection in modo non sempre prevedibile e per periodi di tempo non determinabili a priori; questo tipo di comportamento può creare notevoli problemi in ambienti che necessitano di basse [[Latenza|latenze]] di risposta o in [[Sistema real-time|sistemi real-time]] o mission critical, con possibili malfunzionamenti, [[deadlock]], e arresti che possono compromettere l'intero sistema. Inoltre, tutta la memoria di lavoro deve essere esaminata, minimo due volte, causando potenzialmente problemi nei sistemi a [[memoria virtuale|memoria paginata]].

Riga 121:

==== Generational Garbage Collector (Ephemeral Garbage Collector) ====

È stato osservato che in molti programmi gli oggetti più recenti, sono anche quelli con più probabilità di diventare rapidamente irraggiungibili<ref group="N">Effetto noto come Ephemeral o Generational Garbage Collection.</ref>. L'ipotesi generazionale divide gli oggetti in generazioni. Inoltre il sistema di [[Run-time|runtime]] mantiene la conoscenza di tutti i riferimenti tenendo traccia dalla loro creazione, alla sovrascrittura dei riferimenti. Quando il Garbage Collector va in esecuzione, può essere in grado di utilizzare tale conoscenza per dimostrare che alcuni oggetti inizialmente nel set iniziale bianco non sono raggiungibili senza dover attraversare l'intera struttura di riferimento. Al fine di attuare questo concetto, molti Garbage Collector generazionali utilizzano aree di memoria separate per i diversi livelli degli oggetti. Quando una regione è piena, i pochi oggetti referenziati nella vecchia memoria sono promossi (copiati) nella regione immediatamente successiva per cui l'intera regione può essere sovrascritta con nuovi oggetti. Questa tecnica permette di incrementare la velocità, in quanto la raccolta dei rifiuti di una sola regione avviene nello stesso momento.

Generational Garbage collection è un approccio [[Algoritmo euristico|euristico]] e alcuni oggetti irraggiungibili non possono essere recuperati ad ogni ciclo. Talvolta può quindi essere necessario recuperare tutto lo spazio disponibile. In effetti, i sistemi di runtime per i moderni linguaggi di programmazione (come [[java (linguaggio di programmazione)|java]]) di solito usano alcune varianti delle diverse strategie che sono state descritte sino ad ora.