Tweet
Teoricamente il GC dovrebbe liberare tutta la memoria e ricompattarla, in pratica questo non succede altrimenti dopo il "clearing resources" il lag cesserebbe, cosa che, come tutti sappiamo, non succede.
L'unica risposta che ho trovato è il particolare comportamento del GC con oggetti che prevedano una finalizzazione, questi oggetti non vengono liberati ma accodati in una lista, un thread periodicamente provvede alla finalizzazione degli oggetti nella lista.
Il lag potrebbe essere l'intervento di questo thread.
Il problema principale con la finalizzazione è che se un oggetto da finalizzare è la radice di un albero di altri oggetti, magari un GROSSO albero con megabytes di roba appesa, tutto l'albero non viene toccato dal GC prima che l'oggetto radice sia finalizzato dal thread.
Altra possibile fonte di problemi è il meccanismo delle "generazioni" di oggetti, il GC divide gli oggetti secondo il loro arco di vita in "generazioni" per ottimizzare l'operazione per il recupero della memoria. Una nota che ho trovato in MSDN suggerisce che oggetti con ciclo di vita "medio" possano occupare spazio per un lungo tempo in memoria senza che il GC li tocchi perchè sono finiti nella "generazione 2".
Si suggerisce che gli oggetti abbiano un ciclo di vita o molto breve o molto lungo (magari tutto il tempo di up del server) e che comunque venga evitata la finalizzazione, specialmente per oggetti che sono radice per altri oggetti.
Il GC sembra rendere le cose più semplici, e forse per progetti lameri è così, ma quando si va su sistemi complessi allora diventa più una palla al piede che altro. Java non è che sia meglio di .NET per la cronaca.
Una richiesta, sarebbe possibile vedere il codice del "Clearing resources" ?
Magari si dovrebbe inserire una risincronizzazione forzata con il thread finalizzatore, se già non c'è.
L'unica risposta che ho trovato è il particolare comportamento del GC con oggetti che prevedano una finalizzazione, questi oggetti non vengono liberati ma accodati in una lista, un thread periodicamente provvede alla finalizzazione degli oggetti nella lista.
Il lag potrebbe essere l'intervento di questo thread.
Il problema principale con la finalizzazione è che se un oggetto da finalizzare è la radice di un albero di altri oggetti, magari un GROSSO albero con megabytes di roba appesa, tutto l'albero non viene toccato dal GC prima che l'oggetto radice sia finalizzato dal thread.
Altra possibile fonte di problemi è il meccanismo delle "generazioni" di oggetti, il GC divide gli oggetti secondo il loro arco di vita in "generazioni" per ottimizzare l'operazione per il recupero della memoria. Una nota che ho trovato in MSDN suggerisce che oggetti con ciclo di vita "medio" possano occupare spazio per un lungo tempo in memoria senza che il GC li tocchi perchè sono finiti nella "generazione 2".
Si suggerisce che gli oggetti abbiano un ciclo di vita o molto breve o molto lungo (magari tutto il tempo di up del server) e che comunque venga evitata la finalizzazione, specialmente per oggetti che sono radice per altri oggetti.
Il GC sembra rendere le cose più semplici, e forse per progetti lameri è così, ma quando si va su sistemi complessi allora diventa più una palla al piede che altro. Java non è che sia meglio di .NET per la cronaca.
Una richiesta, sarebbe possibile vedere il codice del "Clearing resources" ?
Magari si dovrebbe inserire una risincronizzazione forzata con il thread finalizzatore, se già non c'è.
Commenta