Garbage collection: differenze tra le versioni

Versione delle 08:54, 27 set 2017

Versione delle 01:02, 21 gen 2018

Riga 4:

Nota: la voce non sembra essere stata ottenuta COMPLETAMENTE mediante traduzione automatica (vedi [[Teplate:Da correggere]])

-->

In [[informatica]] per '''garbage collection''' (letteralmente ''raccolta dei rifiuti'', a volte abbreviato con '''GC''') si intende una modalità automatica di [[gestore della memoria|gestione della memoria]], mediante la quale un [[sistema operativo]], o un [[compilatore]] e un modulo di [[run-time]], liberano le porzioni di [[memoria (informatica)|memoria]] non più utilizzate dalle [[applicazione (informatica)|applicazioni]]. In altre parole, il ''garbage collector'' annoterà le aree di memoria non più ''referenziate'', cioè allocate da un [[processo (informatica)|processo]] attivo, e le libererà automaticamente. La garbage collection è stata inventata nel 1959 da [[John McCarthy]] per il [[linguaggio di programmazione]] [[Lisp]].<ref>{{Cita web|url=http://portal.acm.org/citation.cfm?id=367177.367199 |titolo=Recursive functions of symbolic expressions and their computation by machine |editore=Portal.acm.org |data= |accesso=29 marzo 2009}}</ref><ref>{{Cita web|url=http://www-formal.stanford.edu/jmc/recursive.html|titolo=Recursive functions of symbolic expressions and their computation by machine, Part I|accesso=29 maggio 2009}}</ref>

Questo meccanismo ha condotto ad un notevole cambio nello stile di [[Programmazione (informatica)|programmazione]] dei [[Linguaggio di programmazione|linguaggi]] che lo implementano. Infatti non è più necessario richiedere esplicitamente la liberazione della memoria utilizzata da un [[programmazione orientata agli oggetti|oggetto]], ovvero ''terminare'' tale oggetto in modo deterministico, ma si lascia che il sistema esegua questa operazione automaticamente, nel momento in cui lo riterrà più opportuno al fine di migliorare le prestazioni complessive. Tale azione viene definita nell'ambito delle ''finalizzazioni non deterministiche''.

Riga 11:

Per la gestione della memoria si tiene conto di due principi fondamentali:

# Trovare gli oggetti in un [[programma]] ai quali non sarà più necessario accedere;

# Recuperare le [[risorsa informatica|risorse]] che sono state 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 alla necessità di manipolare direttamente, da parte del programmatore, i [[puntatore (programmazione)|puntatori]] alle varie aree di memoria che contenevano gli oggetti utilizzati durante l'[[esecuzione (informatica)|esecuzione]], ma già rilasciati per altri usi.<ref>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]], garbage-collected, ma consentono all'utente di eliminare manualmente gli oggetti, o, volendo velocizzare il processo, o addirittura disattivare la gestione automatica del sistema '''GC'''. La garbage collection è quasi sempre strettamente integrata con l'[[Allocazione dinamica della memoria|allocazione di memoria]].

=== Benefici ===

La ''garbage collection'' esonera il programmatore dall'eseguire manualmente l'allocazione ( richiesta ) e la deallocazione ( rilascio) di aree di memoria, riducendo o eliminando del tutto alcune categorie di bugs:

* ''[[Dangling pointer|'''Dangling pointers''']]'': persistenza nel programma di puntatori che si riferiscono ad aree di memoria che contenevano oggetti, ma che sono stateormai deallocate. Utilizzare tali aree di memoria deallocate può, nel migliore dei casi, provocare un errore fatale dell'applicazione, ma si possono manifestare altri problemi anche a distanza di tempo dalla effettiva deallocazione. 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>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.

Riga 31:

La ''garbage collection'' presenta tuttavia anche alcuni svantaggi:

* '''Consumo di risorse di calcolo''' : il processo consuma risorse di calcolo, al fine sia di tenere traccia dell'utilizzo delle varie aree di memoria, sia di poter decidere il momento e la quantità di memoria da liberare;

* '''Incertezza del momento in cui viene effettuata la GCGarbage Collection''': Il momento in cui viene effettuata latale collectionoperazione non è prevedibile: questa incertezza può determinare improvvisi blocchi o ritardi nell'esecuzione. Problemi di questo genere sono inaccettabili in ambienti [[real-time]], nel rilevamento di [[driver|driver periferici]], e nell'[[transaction processing|elaborazione di transazioni]];

* '''Rilascio della memoria non deterministico''': analogamente, sia il momento in cui una data area di memoria viene rilasciata, sia l'ordine di rilascio delle varie aree non più utilizzate, dipendono dal particolare [[algoritmo]] implementato dal ''garbage collector''. Si può dire che il rilascio di memoria avviene in modo non deterministico.

* '''Presenza di memory leak''': i [[memory leak]], perdita o fuoriuscita di memoria, possono comunque verificarsi, nonostante la presenza di un '''GCGarbage Collector.''' Ciò può accadere se il programma mantiene un riferimento ad oggetti che hanno esaurito il loro ciclo logico di vita nell'applicazione. La presenza di riferimenti attivi comporta l'impossibilità da parte del collector di rilevare l'area di memoria come non utilizzata.<ref>{{cita pubblicazione |autore= Maebe Jonas |coautori= Ronsse Michiel, De Bosschere Koen|titolo=Precise detection of memory leaks|url=http://www.cs.virginia.edu/woda2004/papers/maebe.pdf|accesso=13 maggio 2010}}</ref> Questo può verificarsi, ad esempio, con collezioni di oggetti. Il monitoraggio del ciclo di vita degli oggetti è una responsabilità primaria dello sviluppatore in ambienti ''garbage-collected''.

== Tracing garbage collection ==

Riga 69:

=== Algoritmo di base ===

I '''''Tracing collector''''' sono algoritmi dedicati, in quanto sono in grado di tracciare il set di lavoro della memoria, effettuando la raccolta degli oggetti non più necessari in cicli. 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>Trad.Ing.:"''Marca e butta via''"</ref> in cui il set di memoria viene più volte analizzato.

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