Referenzen statt Objekte für große Speicherstrukturen

[huckfinn]

Hi,

Ich habe mich gewundert, daß Java sehr viel mehr Speicher in einer Lookupstruktur als herkömmliche Sprachen verbraucht (siehe auch
www.java-forum.org/de/viewtopic.php?t=37725). Es ist etwas mehr als das doppelte zum herkömmlichen Code. Der Grund dafür liegt in der üppigen Speicherauslegung für Referenzobjekte. Ein Beispiel, eine TreeMap (AVL-Tree) mit einem Eintrag ..also Klasse Entry <K,V> hat folgende Referenzobjekte:

Key : Objekt - 8 Byte
Value : Objekt - 8 Byte
Left : Objekt - 8 Byte
Right : Objekt - 8 Byte
Parent : Objekt - 8 Byte
color: boolean - hoffentlich 1Byte

Je nach dem wieviel Objekte in den Containern Key und Value eingebettet sind werden für jede "Adressoperation" also Klassenreferenzen noch einmal das doppelte an Speicher verbraucht.

In den "älteren Sprachen" sind Key, Value, Left und Parent Adressen also für 32 Bit-Strukturen 4 Byte also die Hälfte.

Frage, gibt es eine Möglichkeit, das anders zu organisieren ..sprich referenzieren... Oder ist Java, weil es keine Adressoperatoren besitzt auf diesen Mechanismus festgelegt und verbraucht somit per Definition immer das doppelte an Speicher bei Referenzstrukturen (Objekt anstelle von Pointer). Weiß einer von den Gurus was?

Bis denne huck

 

[SlaterB]

zumindest kann man allgemein den Hinweis geben, das Java an sich ja plattformübergreifend ist/ sein soll,
von der Implementierung/ Speichernutzung selber also wenig weiß,

das ist evtl. ein Thema für Virtuellen Maschinen, die Java-Code interpretieren und ausführen,
nichts für Java an sich?

 

[AlArenal]

Korrekt. Java als Sprache hat da wenig mit zu tun. Das sind Implementierungsdetails der VM. Erfahrungsgemäß ist es unabhängig von der tatsächlichen Implementierung eh immer falsch implementiert.

In diesem Falle:
Sinds 64 Bit ist die Verschwendung zu gro. Wären es 32 Bit wär der Adressraum zu klein.

 

[huckfinn]

Ok,

I'm confused ???:L.

..das Java an sich ja plattformübergreifend ist/ sein soll, von der Implementierung/ Speichernutzung selber also wenig weiß,

Der Verweis das man nicht wissen braucht wie was in dem Ding läuft macht mich kirre. Ich kann muß doch als ordentlicher Entwickler, wenn ich eine gute Applikation schreiben will, wissen wieviele Ressourcen ich brauche und wie mein Zielsystem, wie allgemein es durch die JVM auch sein mag es, implementiert. Das kann man doch nicht ins Reich der Heuristik verbannen. "He.. probier mal aus vieviel die JVM auf der Sun verbraucht damit mir die Applikation nicht mit eine HeapOverflow Exception austeigt." ..Und das mach ich dann noch für die anderen Plattformen. Was hat das mit Unabhängikeit zu tun. Oder ich gebe massig Heap frei, ..auch nicht fein, und habe eine potentiellen Resourcenfresser zu implementiert. Es laufen ja noch mehr Prozesse auf einer Maschine.

Und was soll das?

..Erfahrungsgemäß ist es unabhängig von der tatsächlichen Implementierung eh immer falsch implementiert.

Ich dachte man schreibt deterministisches Zeug und nicht fatalistische Mutmaßungen. Alles ander wäre doch nicht professionell.

Warscheinlich sollte man Java doch wieder in die Spielkiste stecken. Schade eigentlich, denn es wünderschöne Softwarekonzepte und endlich eine Reihe von Standerdisierungen gerade hinsichtlich der Algorithmen und Datenstrukturen ..also der ganze Kram unter java.util.*; . Warum die so viel Speicher brauchen ist allerdinges ein Manko.

Was solls, bis denne huck.

 

[SlaterB]

eines ist sicher, ein Java-Programm das auf WinXP 32 MB speicher braucht,
wird in der nächsten Windows-Version 64 MB Speicher belegen

ne ist jetzt nur geraten, aber wie soll denn ein Programm auf Windows und Unix das gleiche tun,
auf verschiedenen Prozessoren, auf Handy mit 500 KB Hauptspeicher und auf den HighEnd-Systemen mit x GB?

das gilt auch für alle anderen Programmiersprachen!!,
sowas kann man allgemein nicht sagen,
der Unterschied ist nur: Java läuft überall (wenn es jeweils eine VM gibt), man weiß nur nicht wie genau


wenn du den Speicher exakt bestimmen musst, na benutze eine andere Sprache,
in Java kannst du ein einfaches Hello World-Programm schreiben und dir sicher sein,
dass ALLEIN die VM für sich schon mal ein paar MB Speicher belegt und ein paar Sekunden zum starten braucht,

wenn du dann noch in deinem Programm ein simples Swing-Fenster aufmachst,
dann braucht vielleicht allein die Swing-Engine wieder eine nicht unerhebliche,
aber dennoch relativ unbekannte Menge an Speicher,

ganz abgesehen von den zur Laufzeit aufgesuchen nativen Graphik-Routinen,
von denen wiederum vielleicht nicht mal die VM weiß, was sie so genau tun und an Speicher verlangen,
hauptsache sie öffnen ein Fenster


so, wahrscheinlich zum großen Teil nicht korrekt beschrieben,
aber die Tendenz sollte richtig sein

wenn du dein System kennst und die VM dazu, dann kannst du sicherlich auch für Java einiges ausrechen,
genau wie in anderen Sprachen, wo man ebenso System und Compiler kennen muss

 

[huckfinn]

Hi,

Hast du Erfahrungen mit dem gcj (Gnujavacompiler)und classpath ..wird das da besser?

bis denne Huck

 

[Roar]

ich hab dir im andern thread geantwortet und bin so frei hier dreist darauf zu verlinken: http://www.java-forum.org/de/viewtopic.php?p=226583#226583

 

[AlArenal]

Der Verweis das man nicht wissen braucht wie was in dem Ding läuft macht mich kirre. Ich kann muß doch als ordentlicher Entwickler, wenn ich eine gute Applikation schreiben will, wissen wieviele Ressourcen ich brauche und wie mein Zielsystem, wie allgemein es durch die JVM auch sein mag es, implementiert. Das kann man doch nicht ins Reich der Heuristik verbannen. "He.. probier mal aus vieviel die JVM auf der Sun verbraucht damit mir die Applikation nicht mit eine HeapOverflow Exception austeigt." ..Und das mach ich dann noch für die anderen Plattformen. Was hat das mit Unabhängikeit zu tun. Oder ich gebe massig Heap frei, ..auch nicht fein, und habe eine potentiellen Resourcenfresser zu implementiert. Es laufen ja noch mehr Prozesse auf einer Maschine.

Und was soll das?

Ich weiß ja nicht was für Monsteranwendungen du entwickelst. Ich entwickle Anwendungen welche in erster Linie funktionieren sollen. Ob ich sie dann mit nem 2 MB kleineren Memory Footprint hinbekommen könnte, ist mir völlig egal. Das vollziehe ich auch nicht nach. Und was die Plattformunabhängigkeit angeht ist die für mich im Job derzeit auch nicht relevant. Wir haben keine Kunden und kennen auch keine potenziellen Kunden, bei denen auf den Arbeitsrechnern etwas anderes als Windows läuft.

Das Ganze sieht im Embedded Bereich oder bei Handys anders aus. Das sind aber Spezialfälle, die eh nicht von der "normalen" VM bedient werden.

..Erfahrungsgemäß ist es unabhängig von der tatsächlichen Implementierung eh immer falsch implementiert.

Ich dachte man schreibt deterministisches Zeug und nicht fatalistische Mutmaßungen. Alles ander wäre doch nicht professionell.

Warscheinlich sollte man Java doch wieder in die Spielkiste stecken. Schade eigentlich, denn es wünderschöne Softwarekonzepte und endlich eine Reihe von Standerdisierungen gerade hinsichtlich der Algorithmen und Datenstrukturen ..also der ganze Kram unter java.util.*; . Warum die so viel Speicher brauchen ist allerdinges ein Manko.

Was solls, bis denne huck.

Mit Erbsenzählerei lässt sich nunmal in der Breite kein Geld verdienen und es interessiert den Kunden auch nicht.

 

[huckfinn]

Ok,

Dann habe ich eine Frage. Angenommen du hast eine Datenbank die ein Indexregister hat (nur die Adressen der dann üppig anwachsenden eigentliche Datensetst). Dieses Register hat eine Cursorvariable und einen Schlüssel als String. Ein webserver muß zeitweilig das Indexregister auslesen. Ein zweites Backend vergrößert bei Aktualisierungen das Register datenbankseitig, du weißt nicht zum Zeitpunkt des Webserverstartes nicht wie groß das Indexregister werden kann. Wie du siehst werden keine Erbsen gezählt. Ich will nur wissen wann ich die Speicherung der Indexstruktur untersetzen muß und wann ohne das der Webserver beim indizieren aussteigt.

Bis denne Huck

 

[AlArenal]

Frag mal einen der selbst Datenabnekn entwickelt. Ich benutze sie lediglich und die Tatsache, dass komplett in Java geschrieben Datenbanksysteme existieren, die problemlos zig Millionen Records und zig Gigabytes an Daten verdauen sagt mir, dass es geht und in dem Fall ist mir "dass es geht" wichtiger als "wie es geht". Das interessiert mich (in dem Fall bin ich gewissermaßen der Kunde) nämlich dann nicht die Bohne. So wenig wie ich ein Auto bauen können muss, um es fahren zu können.

Schau dir den Source von H2 oder Derby oder HSQLDB an. Womöglich findest du da Antworten.

 

[huckfinn]

Hm,

Irgendwie ist es doch unbefriedigend nicht zu wissen was die JVM wann tut. Aber man muß vermutlich mit der Implentierung der selbigen beschäftigen. Es ist wie offensichtlich mit den API's der jeweiligen Betriebsysteme. Umgenau zu wissen was man da bastelt muß man wissen wie sie funktionieren. Wir haben also eine Maschine mehr ..eben eine virtuelle. Ich habe mir das echt einfacher vorgestellt.

Ich danke für alle Hinweise Huck

 

[hupfdule]

Naja, aber das Konzept der VM wurde gerade für solche Fälle entwickelt, da du dir darum keine Platte mehr machen musst. Wenn du alles bis ins kleinste Detail kontrollieren willst, ist Java die falsche Sprache. Das ist bei anderen Sprachen C#, Python, etc. aber sicher nicht anders.

 

[AlArenal]

Inweiweit sollte C# da besser sein? Die CLR ist doch auch nur eine VM...

 

[SlaterB]

Das ist bei anderen Sprachen C#, Python, etc. aber sicher NICHT anders.

?

 

[Guest]

Hi,

Wie ermittelt eigentlich ein Profiler die Strukturgrößen? Faßt der den Bytecode an z.B. den Heap und den Stack?

Bis denne Huck

 

[hupfdule]

Wenn du alles bis ins kleinste Detail kontrollieren willst, ist Java die falsche Sprache. Das ist bei anderen Sprachen C#, Python, etc. aber sicher nicht anders.

Offenbar hab ich mit der Aussage Verwirrung gestiftet. Was ich sagen wollte: In diesen Sprachen hat man so weit ich weiß das selbe "Problem", dass der exakte Speicherverbrauch nicht vollständig vorhergesagt werden kann. Einfach weil das nicht im Konzept der Sprachen vorgesehen ist.

 

[byte]

Also für gewöhnlich entwirft man das Datenmodell und prüft dann, wie ob man Speicherprobleme kriegen könnte oder nicht. Falls ja, dann kann man Maßnahmen ergreifen, den Speicher zu minimieren (z.B. durch Caching). Ich habe aber echt noch nie gehört, dass jemand die Bytes von irgendwelchen Objekten aufaddiert. :roll:

Wir haben mal in nem Praktikum nen CAN-Controller entworfen. Auf dem Microcontroller lief ne abgespeckte Java VM auf iirc nen paar KB RAM. Selbst da hatten wir keine Speicherprobleme. Da war halt Geschwindigkeit ein Faktor (Vermeidung von Strings, "rechnen" mit Bitoperatoren, ...), aber nicht der Speicher.

Also mein Tipp: Leg diesen Optimierungswahn ab oder wechsel die Programmiersprache. Assembler bietet dahingehend dem Entwickler sicher sehr gute Kontrollmöglichkeiten...

 

[huckfinn]

Hi,

Es gibt ein ganz einfaches Beispiel der mit Optimierungswahn nichts zu tun hat. Angenommen du hast ein Bild z.B. ein CMKY oder ein Satellitenbild mit 4 oder 8 Kanälen, das Bild ist 1024x1024 Pixel groß und jeder Wert hat ein Byte Quatisierungsgröße. Du mußt davon ein mehrdimensionales ein Histogramm davon bauen. Einen adressierende Speicherstruktur dafür wäre

 int a[][][][]... Zahl der Kanäle = new int[1024][1024][1024][1024]...;

Es ist offensichtlich, daß der Speicher sofort platzt. Allerdings ist die Anzahl der möglichen Histogrammwerte nur Kanalanzahl x Megabyte. Mehr kann nämlich im Bild nicht drin sein. Das Speichesystem ist also schwach besetzt. Es ist also günstiger eine Suchstruktur zu benutzen z.B. eine

TreeMap

mit einem N-Kanaligen Schlüssel und einem

int

für das Histogramm der hochgezählt wird wenn der Schlüssel schon im Baum ist oder einen neuen Schlüssel erzeugt mit dem Histogrammwert 1 erzeugt wenn nichts gefunden wird. Also ist alles gut. Wenn ich jedoch jetzt ein Histogramm aus mehreren TreeMaps zusammenziehen will dann muß ihre Speichergröße kontollieren können um irgend wie wiederum zwischen Laufzeit und Speicher zu teilen und zu herrschen (.z.B Histogramminseln zu klassifizieren und rauszuswappen).

Nur son Beispiel Huck
:wink:

 

[huckfinn]

Ups kleiner Fehler es muß

int a[][][][]... Zahl der Kanäle = new int[255][255][255[255]...;

heißen der Speicher platz trozdem. Huck

 

[byte]

Also bei CMYK werden die Farbwerte prozentual gespeichert, das heisst Dein Histogramm wird so initialisiert:

int[][][][] cmyk = new int[100][100][100][100];

Der Farbraum ist also nicht viel größer als bei RGB:

int[][][] rgb = new int[255][255][255];

Lässt sich also problemlos darstellen, allerdings nicht mehr mit der Standard Heapsize von 64 MB. Insofern hast Du schon recht. Ein Integer sind nun mal 32 bit Zahlenraum und Speichergröße in Java. Und ich bezweifel mal stark, dass andere Sprachen 32 bit in weniger als 32 bit Speicher kriegen.

Ich verstehe Deine Kritik also nicht so wirklich. Und ich weiss auch nicht wirklich, was Deine geschilderten Problemfälle nun explizit mit Java zu tun haben. Das sind generelle Probleme, die in allen Sprachen existieren.