Garbage collection: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: sintassi grassetti |
m Bot: disambiguazione wikilink |
||
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 [[sistema 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''.
Riga 75:
Nel ''mark-and-sweep'' ogni oggetto in memoria possiede un [[flag]], in genere è sufficiente un [[bit]], riservato esclusivamente per l'utilizzo del Garbage Collector. Quando l'oggetto viene creato, il [[flag]] viene posto in stato, ''flag clear''<ref name=":0">Trad.Ing.:"''Non in uso''"</ref>. Durante la prima fase, o '''fase di Mark''' del ciclo di Garbage Collection, viene scansionato l'intero set di [[Root (informatica)|root]], ponendo ogni oggetto in stato di ''flag set.''<ref name=":1">Trad.Ing.:"''In Uso''"</ref> Tutti gli oggetti accessibili dalla radice del set sono anch'essi contrassegnati come in stato di ''flag set''.<ref name=":1" /> Nella seconda fase, o '''fase di Sweep''', ogni oggetto in memoria viene ancora una volta esaminato; quelli che hanno ancora il ''flag clear''<ref name=":0" /> non sono raggiungibili da nessun programma o dato, e la loro memoria viene quindi liberata. Per gli oggetti che sono marcati flag set, il flag viene posto in stato ''flag clear''<ref name=":0" />, preparandoli per il prossimo ciclo di Garbage Collection.
Questo metodo ha diversi svantaggi, per esempio, l'intero sistema viene sospeso durante la Garbage Collection in modo non sempre prevedibile e per periodi di tempo non determinabili a priori; questo tipo di comportamento può creare notevoli problemi in ambienti che necessitano di basse [[Latenza|latenze]] di risposta o in [[
==== Tri-colour marking ====
Riga 134:
=== Implicazioni ===
I ''tracing garbage collection'' richiedono talvolta [[overhead]] impliciti a volte indipendenti dalla volontà del programmatore, portando a problemi di prestazioni. Per esempio i ''stop-the-world garbage collection'' durante le pause di esecuzione del programma, effettuano arbitrariamente raccolta di rifiuti, ciò è inadeguato per alcuni [[sistemi embedded]] ad alte prestazioni, per [[server]] e altre applicazioni con esigenze [[sistema real-time]]. Le differenze principali tra allocazioni manuale e automatiche consistono in:
'''Allocazione heap manuale''':
| |||