Newsgroup: it.comp.java
Titolo: Aumento dimensione memoria durante esecuzione

E' possibile aumentare la dimensione massima della
memoria allocata da un programma
(per intenderci quella regolata dal parametro
-Xmx del comando java) dall'interno del
programma stesso?
Mi piacerebbe scrivere una cosa del tipo
try{
  operazioneCheConsumaMemoria();
}catch(OutOfMemoryError e) {
  aumentaDimensioneHeap();
  riprendiEsecuzione();
}
Leggendo dei vecchi thread, ho visto che
qualcuno consigliava di scrivere:
try{
  operazioneCheConsumaMemoria();
}catch(OutOfMemoryError e) {
  System.gc();
}
Altri pero' affermavano che la garbage collection
e' invocata automaticamente dalla JVM prima di
lanciare una OutOfMemoryException.
Voi cosa ne pensate?
Grazie
Ciao
Franco

 E' possibile aumentare la dimensione massima della
Non credo sia posssibile
La VM gira in una shell che riceve la memoria dalla variabile -X
e credo l'unico modo per aumentarla sia chiudere e riaprire la shell
per quanto riguarda la GC, non ci penserei proprio
sicuramente viene auto invocata prima di una out of memory
e comunque agisce frequentemente da sola e libera poco alla volta
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 lanciare una OutOfMemoryException.
Quasi sicuramente la JVM invoca il gc prima di OutOfMemory.
Cmq è sconsigliato "comandare" (via codice) il garbage collector a ripulire
gli oggetti dall'heap, in quanto è un "processo"
interno alla JVM, insomma una sua politica di gestione (che funziona anche
piuttosto bene) della memoria.
Il problema è che il throws della OutOfMemory non deve mai verificarsi e
questo lo puoi  controllare gestendo opportunamente le risorse che hai
utilizzato nel tuo programma (tipo connessioni al db rimaste aperte).
G.M.

In effetti tempo fa c'è stato un interessante dibattito su questi 
argomenti, ma è roba "tosta", che non si risolve con due tips'n'tricks...
Ad ogni modo, se hai voglia prova questa applicazione:
http://www.hp.com/products1/unix/java/java2/hpjtune/
è un tool free della HP per analizzare i log del garbage collector. A me 
è stato molto utile per stabilire quanta memoria assegnare alla JVM, è 
stato in alcuni casi paradossale: per evitare gli out of memory ho 
dovuto diminuirla !
DA PROVARE
-- 
  -- + Setaceous Pig + --
http://megadix.users.mcs2.netarray.com/
http://www.jroller.com/page/megadix/

 dovuto diminuirla !
Gasp! Mi spiegeresti perche'?
(A proposito, grazie a tutti quelli che mi
hanno risposto)
Ciao
Franco

 
Premessa: non prendere per oro colato tutti i "trucchettini" sulla 
garbage collection, devi capire tu cosa non va.
Nel mio caso specifico:
- applicazione batch
- pochi utenti
- throughput molto variabile, ma in generale a "raffiche" di medio-corta 
lunghezza
- settavo -Xmx a 256 mega
Analizzando con il suddetto mi sono accorto che passava pių del 30% 
('stica) in garbage collection, e ogni tanto andava in out of memory. 
Leggendo qua e la (soprattutto il sito di IBM Developer Works) ho 
scoperto che non solo la JVM pagina quando supera il limite max per lo 
heap, ma anche il sistema operativo !
In sostanza:
- la JVM quando aveva bisogno di memoria, la chiedeva al SO
- quando il limite heap veniva superato (nella JVM), scattava il paging 
(sempre nella VM)
- il SO ci metteva del suo, paginando a sua volta ! In pratica le 
paginazioni si sovrapponevano sulla linea temporale...sigh...
- questo perchč veniva perso un sacco di tempo
Allora ho diminuito progressivamente le dimensioni max, fino a circa 80 
mega (valore assolutamente arbitrario), e gli out of memory sono 
spariti...beh quasi...devo ancora lavorarci :)
Buon tuning !


 spariti...beh quasi...devo ancora lavorarci :)
Secondo me č avvenuto questo perchč nel computer dove eseguivi l'applicativo
avevi 256  (+o- 100 Mb) di memoria.
Quindi la JVM allocava senza pensarci troppo fino a 256  Mb, ma questo
procurava una pressione maggiore sulla paginazione del SO mentre la JVM
utilizzava pochissimo il GC, tanto di ram c'enera per lei. Diminuendo la
dimenzione (-Xmax) della JVM hai equilibrato questo sistema.
Ciao
Domenico