# Speicherverbrauch Objekt-Referenz



## bananenkasper (14. Okt 2010)

Hallo zusammen,

vermutlich ist es viel zu offensichtlich, konnte es bisher per  Google nicht definitiv klären:
Wie viel Speicherplatz verbraucht eine Referenz auf ein Objekt?
Also nicht das Objekt selbst, sondern nur eine Referenz auf das Objekt.

Ich vermute mal dass es in einem 32bit-System 32 bit also 4 byte sind?
Unterscheidet sich der verbrauchte Speicher in 32/64 bit Systemen?

Grüße


----------



## XHelp (14. Okt 2010)

Java läuft ja mit VM. Du benutzt also nicht den gesamten Speicher, sondern nur den Heap, der dir zur verfügung stellt.
Wie das Java-spezifisch geregelt ist, kann ich dir auf anhieb nicht sagen. Da wirst du aber vermutlich in der Java language specification fündig. Aber ich denke mal, dass es auf eine logische Adresse hinausläuft.

Es gibt ja 2 Arten von Speicheradressen: logisch und physikalische.
Physikalische ist das, womit man direkt auf den Speicher zugreift.
Aber aus Sicherheitsgründen und Bequemlichkeit gibt es auch die logischen Adressen. Das sind die Adressen, die ein Programm sieht. Da hast du dann eine Seitennummer und Offset. Jede Seitennummer stellt eine Basisadresse dar, die aber aus Platzgründen ausgelagert wird. Diese Basisadresse wird dann um "Offset" verschoben und so bekommst du die physikalische Adresse.
Am besten schappst du dir irgendeine Literatur über Betriebsysteme, wo Speicherverwaltung behandelt wird. Da wird es vermutlich anschlaulicher beschreiben sein.

Bei 32bit-Systemen ist eben der Seitenrahmen 32 bit. (dadurch kommt ja auch die 4 GB grenze an Speicher). Und die virtuelle Adresse ist dann 4b groß. Bei 64 bit Systemen ist es eben 64 bit groß. Von daher gibt es da schon einen unterschied.


----------



## Sonecc (14. Okt 2010)

Wie wäre es mal mit der Forensuche gewesen? Oder Google?
Let me google that for you

Schon der erste Link liefert Antworten und das ganze auch noch in diesem Forum


----------



## bananenkasper (14. Okt 2010)

Also um es nochmal deutlich zu machen:
Eine Referenz auf ein Objekt verbraucht 4byte Speicher.

Googlen ist manchmal nicht so einfach


----------



## tfa (14. Okt 2010)

bananenkasper hat gesagt.:


> Also um es nochmal deutlich zu machen:
> Eine Referenz auf ein Objekt verbraucht 4byte Speicher.


Nein. Das ist implementierungsabhängig. Jede VM kann das machen wie sie will.


----------



## Sonecc (14. Okt 2010)

Kann ich mir nicht vorstellen. Zumindest nicht bei VMs die als JAVA-Konform zertifiziert sind.


----------



## tfa (14. Okt 2010)

Sonecc hat gesagt.:


> Kann ich mir nicht vorstellen. Zumindest nicht bei VMs die als JAVA-Konform zertifiziert sind.



Ich hab in den VM-Specs nichts entsprechendes gefunden. Die Spezifikation lässt allerdings einige Freiheiten zu, z.B.:



> 3.4
> The Java virtual machine specification does not mandate a concrete value encoding null.
> 
> 3.7
> The Java virtual machine does not mandate any particular internal structure for objects.



Das sind Implementierungsdetails. Die Größe von Referenzen ebenso. Wie schon angesprochen gibt es sicherlich Unterschiede zwischen 32- und 64-Bit-Systemen.

Normalerweise kann einem das als Entwickler auch völlig egal sein. Keine Ahnung, warum der TS das wissen möchte.


----------



## Sonecc (14. Okt 2010)

Danke für die Infos. (Das Unterschiede zwischen 32 und 64 Bit bestehen sollte denke ich klar sein, wird aber auch im anderen Thema angesprochen und hier ebenso)


----------



## bananenkasper (14. Okt 2010)

tfa hat gesagt.:


> Normalerweise kann einem das als Entwickler auch völlig egal sein. Keine Ahnung, warum der TS das wissen möchte.



Warum sollte es dem Entwickler egal sein wie viel Speicher sein Programm verbraucht?

Die konkrete Problemstellung in diesem Fall:
Gegeben ist eine sehr lange Sequenz von Symbolen S aus einem Alphabet A = {a, b, c}.
Diese Sequenz nun als Collection<S> in den Speicher laden, oder doch lieber ein char-Array?
Vielleicht auch die Symbole auf eine byte-Array mappen?
a -> 0x00a, b -> 0x00b, c -> 0x00c.

Bei Sequenzen von mehreren hundert Millionen Zeichen denkt man über solche Fragestellungen nach...


----------



## ice-breaker (14. Okt 2010)

Nur das man bei solchen Sequenzen sicherlich nicht einfach nur die Sequenzen irgendwie im Arbeitsspeicher halten will, sondern mit diesen arbeiten muss.
Und da ist da dann der Speicherverbrauch "irrelevant" weil die Laufzeit der Operationen viel wichtiger wird. Zumal man bei solchen Anforderungen (mehrere hundert Millionen Zeichen sind schon in der platzsparendsten Form hunderte MB) dann auch von viel verfügbaren Speicher ausgehen können muss.


----------



## maki (14. Okt 2010)

bananenkasper hat gesagt.:


> Warum sollte es dem Entwickler egal sein wie viel Speicher sein Programm verbraucht?
> 
> Die konkrete Problemstellung in diesem Fall:
> Gegeben ist eine sehr lange Sequenz von Symbolen S aus einem Alphabet A = {a, b, c}.
> ...


Dann ist die größe einer einzelnen Referenz doch egal, es kommt auf die Gesamtgröße an, inkl. Collection bzw. Array.

[JavaSpecialists 029] - Determining Memory Usage in Java

Jedenfalls richtet kommt da noch mehr hinzu als nur der Speicherverbrauch, wie ice-breaker bereits sagte, ist die Laufzeit und u.U. das verhalten unter mehreren threads auch relevant.


----------



## bananenkasper (14. Okt 2010)

ice-breaker hat gesagt.:


> Nur das man bei solchen Sequenzen sicherlich nicht einfach nur die Sequenzen irgendwie im Arbeitsspeicher halten will, sondern mit diesen arbeiten muss.
> Und da ist da dann der Speicherverbrauch "irrelevant" weil die Laufzeit der Operationen viel wichtiger wird. Zumal man bei solchen Anforderungen (mehrere hundert Millionen Zeichen sind schon in der platzsparendsten Form hunderte MB) dann auch von viel verfügbaren Speicher ausgehen können muss.



Das stimmt so nicht. Klar will man damit arbeiten und klar werden Sie per Buffer gelesen. Es ist dennoch gut wenn man "pro gelesenem Buffer" auf möglichst viele Zeichen zugreifen kann.

Bei intensivem Gebrauch kommt der Garbage Collector nicht mehr mit, da ist es schon wichtig wie viel Speicher pro gelesenem Buffer zugewiesen werden muss.



maki hat gesagt.:


> Dann ist die größe einer einzelnen Referenz doch egal, es kommt auf die Gesamtgröße an, inkl. Collection bzw. Array.
> .



Hö? Die Gesamtgröße der Collection ist direkt abhängig von der Größe der Elemente, genau wie die Größe eines Array.
Dass pro "Wrapper-Typ" noch Speicher dazukommt ist schon klar, aber dieser Speicher fällt praktisch nicht ins Gewicht.


----------

