Heap Size massima di un’applicazione Java

[giannino1995]

Lungo discorso comunque vorrei poter manipolare matrici molto grandi. Non c'è proprio soluzione al mio problema?

[andbin]

Non c'è proprio soluzione al mio problema?

        int variabile_globale = 100;
        int variabile_globale2 = 100000;
        String A[][] = new String[variabile_globale][variabile_globale];
        String valore = "0123456789";
        for (int i = 0; i < variabile_globale2; i++) {
            valore = valore + "0123456789";
        }
        for (int i = 0; i < A.length; i++) {
            for (int j = 0; j < A[0].length; j++) {
                A[i][j] = valore;
            }
        }

E scusa .... che cosa ti aspetti che faccia (anzi, forse per i tuoi obiettivi, che "occupi" in memoria) ??
Proviamo ad analizzare il codice sopra? Ok.

Allora: innanzitutto quando c'è un codice del tipo:

valore = valore + "0123456789";

La cosa certa è che per ottenere la nuova stringa viene prima creato (codice generato dal compilatore) un StringBuffer (o StringBuilder, da Java 5), viene fatto l'append di valore e poi di "0123456789" e alla fine viene invocato toString() per ottenere un String. Lo StringBuffer/StringBuilder viene "buttato" via e finirà poi in pasto al garbage collector.
Essendo in un for, questo si ripete ad ogni ciclo.

Se la memoria è sufficiente e il primo ciclo for riesce a terminare, alla fine quel 'valore' sarà una stringa composta da 10 * (1 + 100000) caratteri. Cioè 1000010 caratteri che (essendo char 16 bit = 2 byte) occuperà 2000020 byte, ovvero ben meno di 2 MByte.

Che sono davvero pochi rispetto ad heap space basilari/tipici di 64/128 MB. Durante i 100000 cicli, come ho detto vengono creati tanti StringBuffer/Builder e String, man mano con contenuto sempre più lungo.
Se il heap space è davvero molto molto ampio oppure (anche se fosse meno ampio) il g.c. riesce a "tenere testa" alle nuove allocazioni che vengono quasi subito buttate via, riuscendo quindi a "collezionarle" e recuperare spazio .... allora il primo ciclo for riesce sicuramente a terminare e come ho detto hai un String che occupa meno di 2 MByte.

Poi c'è il secondo doppio-for, in cui assegni la stringa. Qui non stai duplicando/clonando il contenuto della stringa ma solo copiando il reference! E di reference nell'array ne hai 100 * 100, ovvero 10000 e supponendo che un reference occupi 64 bit (su JVM a 64 bit, però una JVM potrebbe usare i "compressed pointers" con soli 32 bit), hai una occupazione dell'array di circa 80 KByte (un array bidimensionale è un array di array, con l'array principale che è di reference, nel tuo caso 100 reference ad array ognuno di 100 reference).

In sostanza quel codice alla fine causa una occupazione di meno di 3 MByte. Per essere chiari: quel codice funziona anche con un heap max di 64 MByte ( -Xmx64m ).

Quindi ripeto la domanda: che cosa ti aspettavi da un codice del genere? Hai una idea (anche non precisa) di quanto occupano stringhe, reference, array, ecc.... oppure "spari" heap space pensando chissà che cosa?