Datentypen interner Speicherverbrauch x64 long vs. int

[thinktank]

Hallo!
Ich verarbeite sehr große Tabellen und kann mich bei einem Feld zwischen int und long entscheiden. Kurzer Test auf einer 64bit VM mit gleich großen int und long Arrays hat aber im Profiler nur Speicherverbrauch beim long angezeigt, kein int -> Werden hier ints immer als long gespeichert und verarbeitet? Also habe ich hier gar keine Möglichkeit, Speicherverbrauch zu sparen?

Danke und Grüße,
Holger

 

[nillehammer]

int --> 32 bit
long --> 64bit
Dabei ist es egal, mit wieviel bit die JVM oder das OS laufen.

 

[SlaterB]

da nach allen Möglichkeiten zur Sparsamkeit gefragt ist sei in jedem Fall erwähnt,
dass man in einem long zwei int hineinkodieren könnte 😉

 

[thinktank]

Ja, das hatte ich auch so gedacht. Aber ich verstehe das gerade eh nicht. Folgendes Programm allokiert 800 Millionen Bytes, was eigentlich nur der Größe von einem Long-Array entspricht (64bit/8= 8 * 100 Mill Zeilen):

public class NewClass7 {

    public static void main(String[] args) throws InterruptedException {
        int cnt = 100000000;
        long[] longA = new long[cnt];
        int[] intA = new int[cnt];
        
        for (int i=0;i<cnt;i++) {
            longA[i] = i*2;
            intA[i] = i;
        }
        while (0!=1) {
            System.out.println("Ready");
            Thread.sleep(1000);
        }
    }
}

Warum sehe ich dem Speicherabbild kein Wert beim int[] Array sonder nur Speicher für long Array?

Stehe ich da auf dem Schlauch?

 

[SlaterB]

warum auch immer, aber ist das dein einziger Test?
die 800 MB reichen doch offensichtlich nur für das long-Array, dann würde das zweite ja gar keinen Speicher verbrauchen,
kann nicht sein, oder braucht dasselbe Programm ohne int[] weniger, die Hälfte?

den Grund zu kennen wäre schön, aber erstmal doch weiter testen,
was zeigt ein Programm z.B. mit nur einem int[] der Größe 15 Mio.?

wenn immer noch genau dasselbe Bild, wäre es z.B. ein Hinweis das irgendeine Alt-Version analysiert wird, unmöglich ist nichts,

wenn aber 15*4 oder 15*8 MB rauskommt, dann hättest du eine schöne Aussage

 

[nillehammer]

Warum sehe ich dem Speicherabbild kein Wert beim int[] Array sonder nur Speicher für long Array?

Stehe ich da auf dem Schlauch?

Wo auch immer das Speicherabbild herkommt, es passt nicht zum gezeigten Code. Die 32B für das int[] entsprechen nämlich dem Speicherverbrauch eines int-Arrays der Länge 0

int[] leer1 = new int[0];
// oder
int[] leer2 = {};

Kommen Dir die obigen Zeilen evtl. bekannt vor? Hast/Hattest Du so ein Konstrukt evtl. in Deinem Code? SlaterB's Idee mit der älteren Version klingt für mich plausibel. Mal ein "Project -> Clean" gemacht, JAR/WAR neu gebaut o.ä?

 

[nillehammer]

[OT]
Und weil's grad so gut passt, zitiere ich einen meiner Profs: "Wer misst, misst Mist." 😀
[/OT]

 

[Spacerat]

[OT]@nilehammer: Apropos Mist... ein Array der Länge 0 hat nur 12 Bytes. 4 Bytes für die Länge und 8 für die Typ-ID. Da 12 aber nicht durch 8 Teilbar ist (die Länge eines Objektes muss durch 8 Teilbar sein) ergeben sich daraus 16 Byte. Das int-Array in dem Bild hätte also die Länge 4 (8 + 8 + 4 * 4). Was sollte denn sonst in den 16 verbleibenden Bytes stehen? (Quelle)[/OT]
BTW.: Wenn man sich das Bild genauer ansieht, erkennt man, dass es bereits ein wenig nach unten gescrollt wurde, das grosse int[] kann also durchaus bereits vor dem long[] aufgetaucht sein.

 

[nillehammer]

[OT]

Apropos Mist... ein Array der Länge 0 hat nur 12 Bytes. 4 Bytes für die Länge und 8 für die Typ-ID. Da 12 aber nicht durch 8 Teilbar ist (die Länge eines Objektes muss durch 8 Teilbar sein) ergeben sich daraus 16 Byte.

Stimmt!! Ich dachte, dass hier einfach die 32 Bits für die Referenz auf das Array-Objekt reserviert sind. Das war aber tatsächlich Mist, weil hier ja Bytes angegeben sind. Deinem Tipp folgend, habe ich mir das Bild nochmal angeschaut. Dort sind bei Objects Allocated 2 angegeben. 2*16Byte = 32 Byte. So erklärt sich das wohl, zwei leere int-Arrays
[/OT]