Garbage collection: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: disambiguazione wikilink |
m Correzioni varie, rimosso template:Correggere |
||
Riga 1:
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]]
▲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=https://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 provocato 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''.
Line 32 ⟶ 27:
* '''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 [[sistema real-time|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=https://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''.
Line 129 ⟶ 124:
==== Precise contro conservative and internal pointers ====
Alcuni collezionisti in esecuzioni in particolari ambienti possono identificare correttamente tutti i puntatori (riferimenti) di un oggetto che sono perciò detti
Una problematica correlata è quella degli ''internal pointers'' o ''puntatori a campi'' all'interno di un oggetto. Se la [[semantica]] di un linguaggio permette puntatori interni e quindi vi possono essere molti indirizzi che si riferiscono allo stesso oggetto, si rende difficile determinare quando un oggetto è o meno rifiuto. Un esempio è il [[C++]], in cui l'ereditarietà multipla può causare puntatori che si riferiscono ad oggetti di base con indirizzi diversi. Anche in linguaggi come [[Java (linguaggio di programmazione)|Java]], tuttavia, i puntatori interni possono durante il calcolo, per esempio nel riferirsi ad un array, riscontrare problemi e in un programma ben ottimizzato il puntatore corrispondente all'oggetto stesso potrebbe essere stato sovrascritto nel suo registro, in tal modo i puntatori interni hanno bisogno di essere sottoposti a scansione.
| |||