Newsgroup: it.comp.java
Titolo: Memory leak in Java

E' possibile un memory leak in Java, cioè che un oggetto non venga mai 
liberato?
Mi spiego meglio: se ho due oggetti che contengono riferimenti reciproci, 
esempio:
A.ref = B;
B.ref = A;
Ammettiamo che C punta ad A, mentre B è puntato solo da B.ref, se io eseguo:
C = null;
volendo liberare sia A che B, cosa succede?
Forse non mi sono spiegato bene, se così riproverò con un po' di codice.
Fabrizio

 Forse non mi sono spiegato bene, se così riproverò con un po' di codice.
no ti sei spiegato benissimo. il problema è dei gc che fanno
refcounting, hai la garanzia che in java il gc possa
collectare le isole non strongly reachable
-- 
sbi

 collectare le isole non strongly reachable
...Ka2zo di lingua è?

...Ka2zo di lingua è?
In effetti alcuni inglesismi si potevano evitare :) 

 >> collectare le isole non strongly reachable
Comunque sia chi la traduce?

 ha scritto nel messaggio 
news:1150729759.7...@r2g2000cwb.googlegroups.com...


refcounting = conteggio dei riferimenti
gc = garbage collector
collectare = collezionare
strongly reachable =  An object is strongly reachable if it can be reached 
by some thread without traversing any reference objects. A newly-created 
object is strongly reachable by the thread that created it. 
(
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html
) 

 collectare le isole non strongly reachable
Ottimo grazie, è "rilassante" programmare in Java.
Fabrizio

 volendo liberare sia A che B, cosa succede?
Non riesci nel tuo intento.
L'istanza concreta viene candidata al garbage collector quando (in 
parole povere) non è più "puntata" da nessun reference valido. Quindi 
affinchè l'istanza venga candidata alla distruzione non basta togliere 
il riferimento da C, finchè A non viene derefereinzato o esce dallo scope.

 il riferimento da C, finchè A non viene derefereinzato o esce dallo scope.
In realtà per A e B non intendevo variabili ma istanze di oggetto. Solo "C" 
era una variabile.
Comunque come ha detto Roberto si genera un'isola che viene correttamente 
rilevata dal gc. Volevo sapere questo.
Grazie,
Fabrizio

 [...] finchè A non viene derefereinzato o esce dallo scope.
typo a parte:
http://en.wikipedia.org/wiki/Dereference
  "Accessing the value that a reference refers to is called
   dereferencing it."
direi che intendevi più o meno il contrario
-- 
sbi

 "C" era una variabile.
Ok, non mi era chiaro.

 direi che intendevi più o meno il contrario
Si, mi sono capito da solo.

 devono essere riavviati periodicamente.
Hai ragione, anche questo in effetti può essere visto come un memory-leak.
Fabrizio


Ma si puo'  veramente definire come buco di memoria questo?
Intendo c'e' una grossa differenza tra l'esempio che hai mostrato e ad 
esempio quello che avviene con i puntatori:
int* pt = new int[1000];
pt = NULL;
dopo quell'istruzione la memoria allocata con la prima istruzione e' 
irrimediabilimente persa.
Quindi buco di memoria mi sembra un termine adatto.
Invece nel tuo esempio, dopo
obj.wasteMemory();
la memoria non e' irrimediabilmente persa. Cioe' il fatto che sia persa o 
meno dipende dall'esecuzione del programma stesso.
A me sembrano due cose diverse... 

 esempio quello che avviene con i puntatori:
So cosa avviene con i puntatori.
Dai però un occhiata a questi articoli (pescati quasi a caso su google) 
e dimmi cosa ne pensi.
http://www.mokabyte.it/2005/06/profiling.htm
http://dev2dev.bea.com/pub/a/2005/06/memory_leaks.html
http://www-128.ibm.com/developerworks/java/library/j-leaks/


Si e' anche vero che 
http://en.wikipedia.org/wiki/Memory_leak
 scrive:
"The term is somewhat of a misnomer, since memory is not leaked or lost from 
the computer, but rather no longer available for use."
che dice il memory leak si ha se la memoria non e' piu' disponibile (non 
vero per l'esempio Java, vero invece per l'esempio C++). A parte questo nel 
seguito non ho effettivamente trovato nulla contro il tuo esempio.
Comunque ho notato una certa vena polemica, ma guarda che ti stavo chiedendo 
con la massima umilta'.

 con la massima umilta'.
Non è affatto polemica, ti ho solo mostrato alcuni articoli dove viene
affrontato il problema.
E nel mio esempio, non è un caso che ho usato il modificatore
"private" alla collection. Essendo visibile solo all'interno della
stessa classe, tutto il resto del programma non può farci nulla. A
dimostrazione di come un bug di una classe mal progettata può causare
un memory leak vero e proprio nel programma.

"private" alla collection.
Giusto, non l'avevo notato :) 

 writes:
c> collectare = collezionare
Raccogliere. Garbage Collecting non è la collezione dell'immondizia :)
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

fdv ha scritto:


In realtà questa cosa è vera, ma dipende dall'algoritmo di GC. Agli albori
quanto prospettato in 
questo thread era possibile, proprio perchè i primi gc facevano reference
counting, mentre oggi sono 
molto più sofisticati. Volendo essere pignoli, non puoi farci conto: non
mi risulta che la VM abbia un 
qualche obbligo sul tipo di GC da usare.
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 qualche obbligo sul tipo di GC da usare.
Esatto. L'algoritmo di GC e' dipendente esclusivamente
dal tipo di JVC, e puo' cambiare radicalmente da versione
a versione e da sistema operativo a sistema operativo.
Per questa ragione il software in esecuzione non puo'
influire in maniera incisiva sull'utilizzo della memoria
e sulla sua liberazione.
  Raffaello

 a versione e da sistema operativo a sistema operativo.
D'altra parte però "de facto" le JVM su cui ho visibilità non fanno più
reference counting da un sacco 
di tempo, su nessuno dei sistemi operativi supportati


 di tempo, su nessuno dei sistemi operativi supportati
Avete ragione, scusate.
L'unico riferimento nelle specifiche della jvm dice soltanto:
"As an example, if a circularly linked group of unfinalized objects
becomes unreachable, then all the objects may become finalizable
together."
In compenso in "The Java programming language 4th ed
(Arnold,Gosling,Holmes)" 17.2:
"[...] One obvious model of garbage collection is reference
counting. [...] Reference counting fails in the face of cycles. [...]
The simplest model of garbage collection not subject to this problem is
called mark-and-sweep. [...] We present mark-and-sweep as a relatively
simple mental model for you to use to understand garbage collection."
E' da questo che ho sempre assunto che in presenza del gc, esso
garantisse la possibilità di pulire un ciclo non strongly reachable.
In "Sun Certified Programmer for Java 5 study guide (Sierra,Bates)":
"[...] With this background information, we can now say with stunning
clarity and resolve that an object is eligible for garbage collection
when no live thread can access it"
Ma anche qui si potrebbe far notare la non troppo sottile differenza
tra essere eligibili e la capacità del gc di poter effettivamente
collectare.
Il primo riferimento è vago (probabilmente volutamente) per quanto
sicuramente attendibile.
Sugli altri si potrebbe dubitare anche dell'attendibilità ( per quanto
gli scrittori non siano.. Schildt )
Credo l'unica asserzione che si possa fare a questo punto è che un isola 
non strongly reachable sia eligible for garbage collection, che poi il 
gc abbia veramente possibilità di reclamare l'isola è un altro discorso.
-- 
sbi

 gc abbia veramente possibilità di reclamare l'isola è un altro discorso.
In ogni caso, tutte le VM (sicuramente dalla 1.3, ma probabilmente anche
da prima) lo fanno. Qual'è il 
tuo problema di preciso?


 tuo problema di preciso?
nessuno
-- 
sbi