Garbage collection: differenze tra le versioni

Versione delle 12:28, 22 apr 2019

Versione delle 17:59, 1 mag 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 di 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=httphttps://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 34:

* '''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=httphttps://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 161:

Ci sono due principali svantaggi per il conteggio dei riferimenti:

* Se due o più oggetti rimandano l'uno all'altro, possono creare un ciclo in cui non vengono mai rilasciati ed il loro riferimento viene valutato zero. Alcuni sistemi di Garbage Collector, come quello in CPython, utilizzano uno specifico conteggio dei riferimenti per affrontare questo problema.<ref>{{Cita web|url=httphttps://www.python.org/doc/2.5.2/ext/refcounts.html|accesso=13 novembre 2008|data=21 febbraio 2008|titolo=Reference Counts|sito=Extending and Embedding the Python Interpreter|citazione=While Python uses the traditional reference counting implementation, it also offers a cycle detector that works to detect reference cycles.|urlmorto=sì|urlarchivio=https://web.archive.org/web/20081023133624/http://www.python.org/doc/2.5.2/ext/refcounts.html|dataarchivio=23 ottobre 2008}}</ref>

* Nelle implementazioni più semplici, ogni assegnazione di riferimento, ed ogni riferimento perso, richiedono spesso modifiche di uno o più contatori di riferimento. Quando viene utilizzato in un ambiente [[multithreading]] tali modifiche, di incremento/decremento, possono essere intrecciate, ma tale operazione risulta costosa per processi senza operazioni atomiche, come Compare-and-swap. Un importante vantaggio del contatore dei riferimenti è che esso fornisce un Garbage Collector deterministico.

Riga 198:

== Ambienti limitati ==

Il Garbage Collector è raramente usato in ambienti di tipo embedded o real-time a causa dell'esigenze di tali ambienti. Tuttavia, sono stati sviluppati Garbage Collector compatibili per questi ambienti limitati<ref>[httphttps://portal.acm.org/ft_gateway.cfm?id=1140392&type=pdf&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184618 Wei Fu and Carl Hauser, "A Real-Time Garbage Collection Framework for Embedded Systems". ACM SCOPES '05, 2005.]</ref>. Microsoft[[Microsoft .NET|.NET Micro Framework]] e [[J2ME|Java Platform, Micro Edition]] sono piattaforme di software embedded che dispongono di Garbage Collection.

== Note ==