Java virtuelle Maschinen können int -sized width auch für short Felder verwenden (dies hängt von ihrer internen Implementierung ab). Nur die Arrays ( short[] ) sind Ausnahmen, bei denen immer garantiert wird, dass sie auch intern weniger Platz als ein int[] beanspruchen. Was ist mit Dalvik ?
z. Ich habe eine Klasse, die 50 Felder vom Typ short enthält. In meiner Anwendung existieren manchmal 10000 dieser Klassen. Dies bedeutet, dass die short -Felder 1 MB Speicher verwenden sollten, aber wenn Dalvik intern 4 Bytes für short -Werte verwendet, dann sind dies 2 MB Speicherverbrauch.
Wie viel Speicher sollte ich von Dalvik erwarten? (Dies bezieht sich auf die Verwendung des internen Speichers, und mir ist bewusst, dass dies möglicherweise nicht durch die Systemspeicherauslastung widergespiegelt wird, z. B. weil Dalvik bereits eine höhere Speichermenge aus dem System reserviert hat.)
In Dalvik sind doppelte und lange Felder 8 Bytes, alles andere (einschließlich kurze) ist 4 Bytes.
Auf der anderen Seite, kurze Arrays nehmen 2 Bytes pro Element (zusätzlich zu vorne Platz für das Array + Objekt Buchhaltung).
Arrays
Die new-array Opcode-Aufrufe dvmAllocArrayByClass (Zeile 71), um Speicherplatz zuzuweisen. Dies ruft dann dvmAllocPrimitiveArray (Zeile 113) auf. Im Schalter in dvmAllocPrimitiveArray wird der Fall 'S' für ein kurzes Array verwendet. Sie können sehen, dass es allocArray (Zeile 38) mit der Breite = 2 aufruft.
In allocArray wird die folgende Berechnung ausgeführt, um die Größe des Arrays zu berechnen:
Kurz gesagt, bei einem 32-Bit-System wäre diese Berechnung:
%Vor%Kurze Arrays benötigen 2 Bytes pro Element.
Felder
Die new-instance Opcode-Aufrufe dvmAllocObject (Zeile 181), um Speicherplatz für das neue Objekt zuzuweisen. Die Größe, die zugewiesen wird, basiert auf dem Feld objectSize von ClassObject . objectSize wird in computeFieldOffsets (Zeile 3543) festgelegt. Wenn Sie jede Instanz von where FeldOffset in dieser Funktion inkrementiert finden, werden Sie bemerken, dass es immer in Schritten von 4 Bytes inkrementiert wird.
Kurze Felder benötigen 4 Bytes.
(Wäre ein Kommentar, aber dafür ist es zu lang.)
Es ist eine ziemlich Routine für 4-Byte-Felder, die für "kurze" lokale vars verwendet werden, da die JVM konzeptionell eine Maschine mit 4-Byte-Registern ist und mit all dem anderen Müll in einem Stapelrahmen nicht viel macht Unterschied.
Für Felder ist es wahrscheinlich abhängig von der Abwägung, Speicher zu sparen, anstatt Zyklen auf Erweiterung und Ausrichtung auszugeben - Erweiterung kostet oft einen kleinen Zyklus und sogar auf Architekturen, die angeblich "agnostisch" in Bezug auf die Grenzausrichtung sind in der Regel eine Strafe für Off-Boundary-Zugriff, so "packen" Felder, ohne sie zuerst neu anordnen, um Wort / Doppelwort-Grenzen beizubehalten kann Leistung kosten.
Wenn also die JVM sich entscheidet, die Felder zu "packen", werden im Allgemeinen die Felder neu angeordnet. Naive JVMs vermeiden Neuanordnungen, da dies mehrere Aspekte der JVM vereinfacht, aber (als ein Beispiel) auf AS / 400 fanden wir, dass aggressive Neuordnung und Komprimierung von Instanzfeldern in der Größenordnung von 30% Leistungsverbesserung für speicherhungrige Anwendungen gewonnen wurden.
Ich habe die Innereien von Dalvik nie gesehen. Standard-Sun-abgeleitete JVMs sind historisch (nicht zuletzt neu betrachtet) abhängig vom Layout / der Reihenfolge der Dinge in der .class-Datei und daher nicht "natürlich" für eine Neuanordnung geeignet. Aber Dalvik stellt die .class-Datei wieder her und ist daher besser in der Lage, die Neuanordnung von Instanzenfeldern durchzuführen.
Beachten Sie, dass zum Testen der Hypothese, dass Dalvik short -Felder packt, Sie eine Klasse mit mehreren Dutzend Instanzfeldern nacheinander erstellen und dann bestimmen müssen, wie groß die resultierende Objektgröße ist. Erstellen Sie außerdem (unter der Annahme, dass das Packing im ersten Fall gesehen wird) eine Klasse mit den Feldern short und int (oder vielleicht long ), die verschachtelt sind, um zu sehen, ob Dalvik sie neu anordnet, um zu packen.