java.lang.OutOfMemoryError: Java heap space: Svuotare la memoria

[Neptune]

Salve a tutti,
il problema è che già qualche tempo fa ho avuto problemi con la memoria che mi terminava, alchè mi sono detto:

1. Miglioriamo l'algoritmo, effettivamente all'inizio era molto inefficiente;
2. Aumentiamo la memoria nell'Eclisse.ini, anche se quest'ultima non gli ha fatto ne caldo ne freddo (anzi un mio collega su Windows 7 riesce a fare molti più calcoli senza manco toccarlo quell'heap, ed io che lo aumentato su Mac Os ne faccio tipo la metà);

Ad ogni modo mi sono accorto che la situazione non può risolversi andando in queste due direzioni, contate che sto facendo un programma di navigazione e su una mappa molto piccola ed un percorso che non come nemmeno tutta la mappa ho roba tipo 500.000 nodi da attraversare ed ogni nodo ha tipo una decina di attributi.

Mi sono quindi chiesto il dubbio, ma se calcolassi prima un pezzettino di percorso, lo salvo o scrivo su un file, poi passo ad un'altro pezzo e così via? così dovrei risolvere, no?

Il problema è che non ho la minima idea di come svuotarlo questo heap, dovrebbe essere il garbage collector ad occuparsene ed invece nulla. Se creo l'oggetto 1, poi passo a creare l'oggetto 2 che nulla a che fare con l'oggetto 1, l'oggetto 2 rimane tranquillamente allocato e difatti la prima "piccola rotta" me la calcola, nel calcolo della seconda mi finisce la memoria.

Secondo voi come posso fare? c'è un modo per invogliare il garbate collector a svuotare la memoria?

Vi ringrazio in anticipo,
Neptune.

[LeleFT]

Senza sapere nulla delle tue strutture dati, di come le allochi, di quale sia il loro scope, eccetera... l'unico suggerimento che ti posso dare è di richiamare System.gc() quando vuoi "dare una spinta" al Garbage Collector.

Tieni però presente che è solo un "invito" al GC, che può tranquillamente essere ignorato dalla JVM.

Detto questo, io cercherei di capire perchè la memoria esaurisce... il più delle volte ci sono problemi di allocazioni "superflue" di grosse quantità di dati che vanno corrette.

Ciao.

[Neptune]

Tra l'altro con un:

System.out.println(java.lang.Runtime.getRuntime().maxMemory());

Mi da come output:

129957888

Quindi mi sa che è rimasto ancora a 128mb e anche se ho cambiato il file eclipse.ini non è cambiato nulla.

[Neptune]

Originariamente inviato da LeleFT
Senza sapere nulla delle tue strutture dati, di come le allochi, di quale sia il loro scope, eccetera... l'unico suggerimento che ti posso dare è di richiamare System.gc() quando vuoi "dare una spinta" al Garbage Collector.

Tieni però presente che è solo un "invito" al GC, che può tranquillamente essere ignorato dalla JVM.

Detto questo, io cercherei di capire perchè la memoria esaurisce... il più delle volte ci sono problemi di allocazioni "superflue" di grosse quantità di dati che vanno corrette.

Ciao.

Che informazioni ti potrei dare per avere consigli più dettagliati?

Cioè se ci fosse un modo per dire a Java DEALOCA TUTTO, o dealloca l'oggetto xyz, allora potrei scrivere la struttura dati su file e svuotare la memoria di volta in volta.

Comunque faccio uso principalmente di ArrayList (di float, o di coppie-terne di float) e l'algoritmo per calcolare la rotta su questa mappa è ricorsivo (altra cosa che riempie lo stack).

Ci ho passato giorni a riscrivere e snellire l'algoritmo ed ora non dico che sia ridotto all'osso ma quasi. L'unica idea realmente risolutiva secondo me è riuscire a calcolare questa rotta per pezzi e svuotare la memoria passo per passo.

Ma se io creo l'oggetto xyz, lo uso, faccio quello che devo e poi nel resto del codice non tocco più xyz ma creo un oggetto xyz2 e inizio ad usare questo nuovo oggetto, il garbate collector dovrebbe deallocarmelo xyz?


EDIT: A quanto pare comunque non dealloca anche con quel gc, ovvero un po' di spazio libero in più ce ma non basta. Forse il fatto che richiamo tutto nello stesso scope (ovvero ho due oggetti pesanti dichiarati di fila nello stesso main) fa si che il gc non possa deallocare.

[rsdpzed]

Originariamente inviato da Neptune
Forse il fatto che richiamo tutto nello stesso scope (ovvero ho due oggetti pesanti dichiarati di fila nello stesso main) fa si che il gc non possa deallocare.

this.

poi se nel corso di una routine nello stesso scope una grossa collezione non ti serve piu la puoi settare a null a quel punto la GC se decide di passare (perchè c'è pressione nell'heap) troverà la collection settata a null e la candiderà per la rimozione.
La GC parte solo se ci sono pressioni in heap e candida per la rimozione tutti gli oggetti orfani.

lo stack non centra nulla con l'heap, non c'è GC. durante la ricorsione nello stack vengono memorizzati solo i riferimenti se internamente la funzione istanzia degli oggetti questi nascono e muoino man mano che si verifica la ricorsione (per via delle uscite dallo scope) e questo praticamente rappresenta un vantaggio in termini di performance dell'heap. Se avessi problemi nello stack l'exception sarebbe una StackOverflowError e non una outofmemory.

[Neptune]

Per quanto ci stia provando e riprovando non sto riuscendo a trovare nessun modo per forzare lo svuotamento della memoria. Così pure se decidessi di salvare su file il risultato intermedio sarebbe inutile perché se tanto la memoria rimane comunque occupata che risolvo?!

E' la prima volta che mi tocca rimpiangere la gestione della memoria del C, è vero che ogni volta con i puntatori ci impazzivi ma adesso un bel distruttore del metodo e via..

[valia]

fammi capire un po (perché forse qualcosa puoi fare), in realtà cosa devi fare?
A quanto ho capito tu hai una serie di punti e da questi crei un percorso, ma per ogni punto tu hai un oggetto (la lista/mappa delle rotte).
Quindi se tu hai un punto (es. il punto 100) vai a colpo sicuro a prendere l'oggetto associato alla chiave 100 e da questo hai le rotte, alla fine una struttura di dimensioni ridotte.
Scrivere su file non aiuta perché in pratica metti la roba in memoria per poi scaricarla (e non subito).
Dovrei avere più dettagli per dare altri consigli, senza saper leggere/scrivere ti dico questo

[Neptune]

Originariamente inviato da valia
fammi capire un po (perché forse qualcosa puoi fare), in realtà cosa devi fare?
A quanto ho capito tu hai una serie di punti e da questi crei un percorso, ma per ogni punto tu hai un oggetto (la lista/mappa delle rotte).
Quindi se tu hai un punto (es. il punto 100) vai a colpo sicuro a prendere l'oggetto associato alla chiave 100 e da questo hai le rotte, alla fine una struttura di dimensioni ridotte.
Scrivere su file non aiuta perché in pratica metti la roba in memoria per poi scaricarla (e non subito).
Dovrei avere più dettagli per dare altri consigli, senza saper leggere/scrivere ti dico questo

La cosa è più complessa.

Ho una mappa su cui i punti sono caratterizzati da longitudine, latitudine e tipo. Dato che devo fare una rotta di navigazioni per nave sostanzialmente il tipo mi serve per capire se è navigabile oppure no. Lo scopo principale infatti è date due rilevazioni, una velocità ed un tempo di navigazione (quindi lo spazio percorso) cercare di ricostruirsi una rotta probabile.

A dirla tutta l'utente deve poter scegliere se lavorare direttamente al massimo del dettaglio, ovvero la mappa reale, oppure raggruppare più punti della mappa in una cella e quindi lavorare con minor dettaglio.

Ora se l'utente lavora con minor dettaglio io sono felice perché raggruppando più dati assieme diminuisce anche il carico in memoria però mi è stato detto di dare anche la possibilità di lavorare al massimo della risoluzione.

Ora con una mappa di prova (isola del giglio e dintorni, guarda un po' ) nemmeno troppo estesa, e con una rotta che non copre manco tutta la mappa mi è capitato di avere a che fare con circa 500.000 punti (e stiamo parlando di mappa piccola e rotta piccola).

All'inizio avevo pensato ad un bel grafo con dei bei nodi, dei bei archi e tutto, peccato che se i nodi erano tanti gli archi erano tantissimi. Poi ho provato un hashmap ma niente nemmeno li. La soluzione finale è che semplicemente mi calcolo dinamicamente solo i punti della mappa che valuto realmente per l'algoritmo di visita, me li tengo "così" in una lista (visto che lavoro su un algoritmo di visita tipo grafo e quindi devo scorrere una lista di adiacenti) e stop. Peccato che anche così si arrivano a creare rotte lunghissime.

Stavo quindi pensando ad una cosa:

Potrei calcolarmi una rotta con una bassissima risoluzione in modo da avere dei punti intermedi, poi tra quei punti intermedi potrei calcolarmi una mappa a risoluzione più alta.
Per farlo però mi servirebbe un qualche modo per salvarmi a parte i risultati intermedi (ed ecco l'idea del file) e poi liberare la memoria.

La memoria cosi che risparmierei sarebbe enorme, perché nell'algoritmo di visita i vari oggetti per costruire la rotta mi allocano memoria per tutti i punti presi in considerazione anche se poi non li sceglie come rotta. Però non saprei proprio come fare in java

[ramy89]

Ho una mappa su cui i punti sono caratterizzati da longitudine, latitudine e tipo. Dato che devo fare una rotta di navigazioni per nave sostanzialmente il tipo mi serve per capire se è navigabile oppure no. Lo scopo principale infatti è date due rilevazioni, una velocità ed un tempo di navigazione (quindi lo spazio percorso) cercare di ricostruirsi una rotta probabile.

Ogni punto è navigabile indipendentemente dalla posizione dalla quale lo si vuole raggiungere?
Perchè se è così non ti serve un grafo, risolvi tutto con una matrice di boolean.
Poi se ci sono tanti punti con valori simili, e ad esempio è comune trovare un segmento di booleano tutti settati a false o a true, puoi memorizzarli con una matrice sparsa.

[valia]

perché per ogni nodo non ti tieni una mappa? mappa con valore mappa lo puoi fare. hai provato o ti sto dicendo una cavolata?
Poi hai provato ad usare delle cache e il concetto di proxy?
cioè ti tieni tutti i dati in memoria, ma in realtà hai una serie di punti che puoi raggiungere solo da un punto.
Mi spiego, tu hai l'isola del giglio (guarda un po' ) ma in realtà hai che da un dato punto non li puoi raggiungere subito tutti. E' inutile considerare, ad un certo livello, punti che stanno dall'altra parte dell'isola. Non so se lo hai già fatto, ma questo esclude un po' di calcoli. Poi per ogni punto devi fissare una serie di direzioni percorribili, ma devi approssimare ogni piccolo spostamento a delle linee.
devi indicare di quanto differenzi gli spostamenti, ovviamente più lo fai più percorsi devi valutare. Nello scegliere un percorso, ne scegli uno probabile (a meno che non sai quali punti devi percorrere). Non so se creandoti delle mappe di prossimità ottieni qualcosa.
attento che io ho solo parte del contesto, sto solo ragionando ad alta voce.

Infine ti dico che un linguaggio come java è poco adatto a questi calcoli, specie se usi algoritmi ricorsivi. non a caso C/C++ rispondono meglio a queste esigenze (lavori su puntatori e hai delle free dirette)