Garbage collection: differenze tra le versioni

Versione delle 21:53, 1 mar 2019

Versione delle 20:09, 6 mar 2019

Riga 4:

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

-->

In [[informatica]] per '''garbage collection''' (termine a volte abbreviato con '''GC''', letteralmente ''raccolta deidi rifiuti'') 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 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|lingua=en |data= |accesso=29 marzo 2009}}</ref><ref>{{Cita web|url=http://www-formal.stanford.edu/jmc/recursive.html|lingua=en|titolo=Recursive functions of symbolic expressions and their computation by machine, Part I|accesso=29 maggio 2009|urlmorto=sì|urlarchivio=https://web.archive.org/web/20131004215327/http://www-formal.stanford.edu/jmc/recursive.html|dataarchivio=4 ottobre 2013}}</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 19:

=== Benefici ===

La ''garbage collection'' esonera il programmatore dall'eseguire manualmente l'allocazione (richiesta) e la deallocazionedelocazione (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, ormai deallocatedelocate. Utilizzare tali aree di memoria deallocatedelocate può, nel migliore dei casi, provocare un errore fatale dell'applicazione, ma si possono manifestare altri problemi anche a distanza di tempo dalla effettiva deallocazionedelocazione. La risoluzione di questi problemi può essere molto difficoltosa.

* '''''Doppia deallocazionedelocazione''''': 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 deallocarledelocarle 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 32:

* '''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 Garbage Collection''': Il momento in cui viene effettuata tale operazione 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 '''Garbage 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''.