Garbage collection: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Recupero di 2 fonte/i e segnalazione di 0 link interrotto/i. #IABot (v1.6.4) |
|||
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 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|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 162:
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=http://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.
|