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

[Pastore12]

Originariamente inviato da Neptune
Tesi triennale

Se mi son perso qualche puntata su OT, ti chiedo scusa...

Domanda: a bassa risoluzione, una cosa come il canale di panama potrebbe sparire? Perché se è così la l'idea di semplificare per trovare una soluzione approssimata e poi "congiungere" le soluzioni ottimali ad alta risoluzione tra i punti intermedi potrebbe non funzionare sempre...

[valia]

allora mi chiedo, perché non usare linguaggi più adatti a gestire quantitativi davvero grossi di dati da elaborare in questo modo? Ti è stato chiesto in java?

Domanda OT lo so, ma da quanto abbiamo capito tutti, hai già implementato le soluzioni che a noi vengono in mente, quindi non è che è java non adatto?


ps @rsdpzed

sul mio pc il tuo test (Test5) arriva a 7 con impostazioni di default della JVM, ma non mi meraviglio che il carico della macchina influisca su questa analisi.

[Neptune]

Originariamente inviato da Pastore12
Se mi son perso qualche puntata su OT, ti chiedo scusa...

Domanda: a bassa risoluzione, una cosa come il canale di panama potrebbe sparire? Perché se è così la l'idea di semplificare per trovare una soluzione approssimata e poi "congiungere" le soluzioni ottimali ad alta risoluzione tra i punti intermedi potrebbe non funzionare sempre...

Non è che abbassando la risoluzione le cose spariscono, abbassando la risoluzione più punti della mappa vengono aggregati assieme nel metodo che mi è stato suggerito in questo thread dal buon satifal:
http://forum.html.it/forum/showthrea...readid=1498133

In pratica semplicemente se la precisione e 100 allora raggruppo quattro punti assieme a formare un quadrato, memorizzandomi invece di 100 set di coordinate solo 2 coordinate comprendenti minimo e massimo del range in cui si trovano quei punti. Inoltre gli spostamenti diminuiranno perché è come se avessi meno punti sulla mappa.

Per capire dove mi posso o non mi posso spostare posso giostrare su un parametro che mi memorizzo in ogni range di nodi che è la percentuale di non navigabilità.
Se so che è una mappa dove nella prossimità potrebbe esserci uno stretto, potrei dire di pasare da quella cella anche se è al 90% non navigabile. Se invece si parla di una circumnavigazione di un isola allora dico di evitarle totalmente le parti che non sono totalmente navigabili.

Devo farla in Java perché la tesi impone questo linguaggio

Tra l'altro io in realtà non è che creerò delle rotte da "partenza" a "destinazione" ma avrò qualcosa come delle rilevazioni ogni tot minuti (rilevazioni ais per chi le conosce) e dovrò ricostruire le rotte in quei pezzi. Però se è vero che potrebbero non capitare rotte enormi (comunque devo informarmi a riguardo), è anche vero che se devo fare piccole rotte ma ripeterle per 100 rilevazioni e l'algoritmo è pesante comunque ci metto una vita.

Ad ogni modo già il fatto che spezzettando comunque riesco ad affrontare rotte più lunghe è già un passo avanti che dire "No, se faccio rotte più grandi non ce la faccio".
Mi sa che ripulisco un po' il codice, aggiusto javadoc e simili e vado a conferire sulla professoressa per capire lei cosa ne pensa a riguardo.

Tra l'altro, parliamo di punti vicinissimi tra loro, e parliamo di un algoritmo che già da precisione 1 (quella reale) a precisione 2 cambia dall'oggi al domani, a precisione 10 praticamente è un razzo.

[Neptune]

In realtà sullo spezzettamento delle rotte un dubbio mi rimane:

Ovvero mi è stato detto di calcolare un percorso possibile, con visita in profondità (e successivamente dovrò vedere anche quella in ampiezza), semplicemente fermandoci o quando troviamo il nodo di arrivo o quando superiamo la lunghezza massima del percorso.

Questa lunghezza massima, lmax, ce la calcoliamo con Tempo * Velocità.

Ora, se io ho lmax per TUTTO il percorso, come faccio poi a dividermela per i sottopercorsi?!?

Io per ora questo parametro lo sto solo "buttando li largo" e appena si arriva a destinazione bene. Ma se devo spezzare la rotta in 5 parti, è ho una lunghezza massima di 100km, come faccio? Cioè se dico che ogni parte è di 20 km magari non è giusto perché magari mi ritrovo una parte in cui navighi in mare aperto tutto dritto e ne fai 5 di km, un'altra parte dove devi aggirare un isola e ne fai 35! Come si fa?

[rsdpzed]

@Nep. Ottimo ora purtroppo le considerazioni sull'efficienza del linguaggio cambiano. Un ambiente managed nasconde tanti scheletri nell'armadio che sono semplicemente ben nascosti. Tanto per farti un esempio tanto stupido quanto assurdo: string s3 = s1 + s2; è un killer di performance ed è per questo che si usano di solito gli string builder. Per quanto riguarda le collection come arrayList Metodi come remove o get se li puoi evitare è molto meglio. Per il resto cerca qualsiasi cosa perchè un minimo cambiamento in positivo si puo far sentire in generale.

@Valia Quel test ovviamente per come è scritto è destinato a fallire alle prime battute. Ma ho questo che è molto interessante e ci puo dare un idea di quanto è potente la GC.

public static void Test3(int i, boolean isStackOverflowReached)
    {
        if (isStackOverflowReached)
            return;

        int stressSize = 5000000;
        int j = 0;
        List l1 = new ArrayList<Integer>();
        while (j < stressSize)
        {
            l1.add(j);
            j++;
        }
        
        System.out.println("STEP " + i + " : " + l1.size());
        i++;
        try
        {
            Test3(i, false);
        }
        catch(StackOverflowError e)
        {
            Test3(i, true);
        }
        System.out.println("Ritorno " +  i );
    }

è una funzione ricorsiva che al suo interno ad ogni chiamata istanzia una collezione enorme. Durante la ricorsione lo scope della collezione l1 NON è finito perche potrei per esempio utilizzarla nella fase di ritorno dalla ricorsione ED INVECE LA GC LA TRASHA perche si accorge dal codice che non viene piu usata! Se l'ultima riga la cambio in

System.out.println("Ritorno " + l1.get(i) );

la collezione non viene piu collezionata dalla GC perchè quest'ultima si accorge che al ritorno dalla funzione l1 deve essere nuovamente usato!

Giuro che se ora .NET non fa la stessa cosa disinstallo visual studio, mi licenzio e passo a java!

Edit: se la vuoi provare chiama Test3(0, false);