Ist es empfehlenswert die 32-Bit Version der JRE auf einem 64-Bit Rechner mit 64-Bit Betriebssystem zu installieren?
Tendenziell würde ich sagen, dass man die Architektur nur mit der passenden Version (also der 64-Bit Version) ausreizen kann. Aber im Hinterkopf habe ich irgend etwas, dass die 64-Bit Version deutlich mehr Arbeitsspeicher braucht als die 32-Bit Version (Variablen werden immer 64-bittig angelegt, auch wenn das nicht notwendig ist) und nicht signifikante Performancevorteile hat. Stimmt das?
Normalerweise ein 64Bit-Java für ein 64Bit-OS.
Unter Windows bzw. für den IE scheint es da aber eine Besonderheit zu geben:
Quelle: http://www.java.com/de/download/faq/java_win64bit.xml
Da du es nicht extra gesschrieben hast welches OS du nutzt.
Auf meinem Windows hab ich eine 32-Bit Vm aus dem Grund den Lex schon darbebracht hat
auf meinem Linux nutze ich dann eine 64 Bit VM
Die Seite habe ich auch schon gelesen. Das dürfte ganz einfach daran liegen, dass eine 32bit-Anwendungen keine 64bit-Anwendung als Plugin ausführen kann. Dieser FAQ-Beitrag zielt daher wohl nur auf die Nutzer des Java-Browserplugins ab.
Es geht um Windows 7 und ein IE-Plugin wird es nicht geben.
Hat jemand Informationen zur Speicherbelegung? Es kann auch sein, dass dieses Phänomen in irgend einem anderen Kontext aufgetreten ist, und ich mich nur falsch erinnere.
*** Edit ***
Ich habe nochmal ein bisschen konkreter gegooglet:
Zusammengefasst: die Objektreferenzen belegen 64 statt 32 Bit und es gibt „Compressed oops“, die den Speichernachteil zu Lasten von Rechenzeit kompensieren.
Vielleicht hat ja jemand noch weitere Informationen zu dem Thema.
Danke fuer deinen letzten Link
der ist fuer mich sogar sehr interessant
so ein Blödsinn - selbst wenn ich auf jeden dusseligen Interger mit Referenzen (oder Pointern) arbeite verbrauche ich unter 32Bit 8 Bytes (4 Byte Referenz und 4 Byte für Wert). Unter 64 Bit brauche ich ganze 12 Bytes (8 Byte für die Referenz und 4 Bytes für den Wert). Ich brauche also theoretisch 33% mehr Speicher. Da wird aber nicht überall nur mit Referenzen arbeiten und bei einigen Objekte mehr als nur 4 Bytes für die Werte verbrauchen, werden die 33% auch wieder weniger. Ich persönlich verstehe unter big reduction mehr als 50% weniger Speicher, was ja noch nicht mal das bescheuerte Integer-Referenzen-Handling von mir am Anfang überschreitet.
Als weiteres sollte es für den Entwickler unterm Strich egal sein ob hier 32 oder 64 Bit verwendet werden. Das problem ist wie schon am Anfang angemerkt der IE/Firefox/Chrome/… welche als 32 Bit keine 64 Bit Plugins verarbeiten. Das gleiche existiert nämlich unter .NET ebenfalls. Eine Assembly die auf Any compiliert wurde wird unter einem 64 Bit BS keine 32 Bit DLL laden können. Das Problem liegt aber schon in der nativen Welt. Kein 64 Bit Programm kann eine 32 Bit DLL laden. Das Problem hat aber keinen Zusammenhang zum Speicherverbrauch.
Es ist nur für den Benutzer interessant welche Bit-Version er von Java verwendet. Je nachdem was er für Browser verwendet - wenn der Benutzer denn überhaupt etwas Ahnung hat was da passiert.
Dann noch wozu das Ganze Speicherverbrauch und Rechenleistung sparen? Wir sind auf einem Desktop-PC und da ist für normale Programme immer genügend Rechenleistung und Arbeitspeicher vorhanden. Wer mal (ernsthaft) einen µC programmiert hat, weis was da für Probleme herrschen.
Das ist jetzt aber etwas pauschal gesagt.
Ich fragte deshalb, weil auf den Zielsystemen die Ressourcen eben nicht allzu üppig sind. Und wenn es 50% Speicherersparnis ausgemacht hätte, dann hätte ich auch die 32-bit JRE verwendet. Dass es keine 50% sind hat sich ja herausgestellt, deshalb habe ich mich entschieden, die 64-bit Version zu verwenden.
Definitionssache - ich bezog mich dazu auf µC
Du kannst es ja ausprobieren - eine 32 Bit VM und 64 Bit VM - und dann mal schauen was passiert
[QUOTE=cmrudolph]Das ist jetzt aber etwas pauschal gesagt.
Ich fragte deshalb, weil auf den Zielsystemen die Ressourcen eben nicht allzu üppig sind. Und wenn es 50% Speicherersparnis ausgemacht hätte, dann hätte ich auch die 32-bit JRE verwendet. Dass es keine 50% sind hat sich ja herausgestellt, deshalb habe ich mich entschieden, die 64-bit Version zu verwenden.[/QUOTE]
Nicht so üppig verstehe ich <4GB RAM und da hat sich die 64bit Frage eh schon erledigt.
Dann hätte ich also doch lieber die 32-bit Version nehmen sollen. Zieht die JRE keine weiteren Vorteile aus der 64-bit Architektur?
Unter 4GB RAM installiert man schon mal kein 64bit Betriebssystem. Daher meine Aussage.
Es sind glatt 4 GB RAM, daher auch 64-bit OS, um sie vollständig zu adressieren. Es laufen aber ziemlich viele Dienste auf dem System, sodass die Ressourcen mit Bedacht eingesetzt werden müssen.
aber es ist egal ob die JVM mit 32 oder 64 Bit läuft - die Unterschiede werden eher gering sein. Und wenn der Rechner permanent mit mehr als 80% Auslastung (egal ob CPU oder RAM) läuft ist er zu klein Dimensioniert.
Falsch. 32bit und PAE und die vollen 4 Gig sind adressierbar. Eizigen Vorteil von der jetzigen 64bit Installation, RAM Erweiterung ist ohne Probleme möglich und sollte überdenkt werden, bevor man irgendwie anders herumscheißt. RAM kostet nicht die Welt, die Arbeitszeit für diverse Würgarounds ist um einiges teurer.
32bit und PAE und die vollen 4 Gig sind adressierbar
Häh, was meinst du ?
windows XP hat man mit bisserl tweaken auf 3,7 GB RAM bringen können. der Verschnitt waren also nur die 0,3GB, die für die IO Adressbereiche draufgehen.
Für die 0,3 GB verwend ich doch dann um Himmels willen kein PAE ! Ich opfer doch ned das lineare Adressmodell wegen den paar Mbytes ^^
PAE nimmt man eigentlich, wenn man massig mehr Speicher hat, aber kein 64bit OS laufen lassen kann …
Und dann natürlich viele 32bit Prozesse laufen laesst, die den speicher auch nutzen … (nen 32bit prozess ohne PAE kann nur 2GB RAM allokieren, zumindest unter windows, unter linux glaub ich aber auch).
grosse Datenbanken sind da das paradebeispiel.
Eizigen Vorteil von der jetzigen 64bit Installation
Und die Performance … naja je nach Speicher allok Philosophie ! Bei PAE musst du für jede Speicheroperation 2x 32bit Register belegen.
Bei x64 reicht wieder 1 (64bit) Register …
keine ahnung was das ausmacht … aber zumindest nen XP mit PAE fühlte sich schon lahmer an … solang man ned an der Speichergrenze kratzt …
Ciao …
Lustig wie du da um XP herumredest. XP ist tot. Und alle 32bit Linuxkernel haben per default PAE aktiviert.
Wie TheDarkRose schon sagte sind mit PAE Kernel auch 4GiB unter 32 Bit OS addressierbar.
Das driftet jetzt ein Wenig vom Thema ab. PAE ist mir durchaus bekannt (wobei ich nicht weiß, ob die vorhandene Hardware das unterstützt). Die Hardware wurde gekauft, bevor ich im Projekt war, zusammen mit dem 64-Bit Windows 7 Professional. Darauf habe ich also keinen Einfluss.
Die Geräte haben 4 GB Hauptspeicher und ein 64-Bit Betriebssystem - das sind die Rahmenbedingungen.
Der Diskussion habe ich jetzt entnommen, dass unter diesen Rahmenbedingungen eine Installation der 64-Bit JVM keinen Vorteil bringt - scheinbar aber auch keinen relevanten Nachteil.
um es mal kurz auf den punkt zu bringen : ob nun 64bit oder 32bit VM unter einem 64bit OS ist für java selbst erstmal jacke wie hose
interessant wird es erst wenn es in richtung native-libs geht
wenn du eine 32bit native hast kannst du diese auch nur mit einer 32bit vm laden … vice-versa mit 64bit
die frage die man sich also hier stellen müsste wäre eigentlich : welchen vorteil bringt es , wenn man natives nutzt , die 64bit varianten zu nutzen … denn das OS (zumindest windows) stellt ja erstmal standardmäßig beides bereit …
ergo : unter windows ist es nur eine frage der genutzten libs … wenns um reines java geht dürfte lediglich der punkt “wie viel RAM / heap die 32bit / 64bit VM verarbeiten kann” interessant sein
(um noch mal salz in die wunde zu streuen : man konnte unter XP einer 32bit VM auch durchaus volle 3GB heap zuweisen (sofern genug RAM im system) … also müsste ja wohl auch dort schon default-mäßig PAE genutzt wurden sein)
unter unix gehts dann schon etwas mehr zur sache
zieht man sich eine “rohe” 64bit-version hat man in der regel das problem das man nur reine 64bit software ausführen kann …
um überhaupt 32bit software nutzen zu können muss man meist erstmal die 32bit-libs nachinstallieren (warum das eigentlich nicht standard-mäßig gemacht wird … who cares)
du hättest also schon probleme die 32bit vm ohne die 32bit-libs überhaupt starten zu können
was das aber wieder für vor- und nach-teile hat ist immer von der verwendeten vm abhängig
und die frage stellt sich auch unter windows : sun/oracle VM oder openjdk ? oder was ganz anderes ? auch das macht unterschiede
die frage “32bit vs 64bit” ist halt zu umfangreich und bedarf viel fachwissen … da spiel java selbst dann eher eine untergeordnete rolle
Wie TheDarkRose schon sagte sind mit PAE Kernel auch 4GiB unter 32 Bit OS addressierbar.
Unter windows nur „halb“ richtig.
Ein „normaler“ 32 bit prozess unter windows, egal welches, kann nur 2^(32-1) bits insgesamt addressieren. Weil das hoechstwertige bit zweckentfremded wird …
Das gilt nicht fuer windows selber … das kann als 32bit system 2^32 bit - Adressbereich für IO Adressen belegen.
IMHO ist das unter linux auch so, aber da bin ich mir ned wirklich sicher …
ein 32bit prozess der „PAE“ verwendet … und der muss extra damit compiliert sein, der brauch andere runtimes und biblios, und ist nicht mit normalen 32bit Prozessen kompatibel, kann sogar weit mehr als 4 GByte adressieren
Der läuft auch nur unter windows 32 mit PAE ! oder windows 64 mit PAE extension libs.
Nen normaler 32bit prozess lauft unter windows 32, windows 32 mit PAE, und windows 64
Lustig wie du da um XP herumredest. XP ist tot.
Naja, windows vista/7 hab ich ned als 32bit … deshalb kann ich nur von XP berichten ^^
Und alle 32bit Linuxkernel haben per default PAE aktiviert.
Der Satz an sich kann richtig sein, oder auch falsch, je nach sichtweisse ^^
Ist bei einer standard 32 bit installation von linux PAE eingeschalten, also nutzt das laufende linux es ? … nein !
Es nutzt das lineare 32 bit model … und PAE kompiliertes würden crashen.
Es ist aber im Kernel „eincompiliert“ (Option PAE Support) - daher es ist als compiler option standardmäßig „aktiviert“.
Um es zu nutzen muss man es noch „manuell“ aktivieren - in dem Falle eine Boot-Option im bootloader setzen.
Dann kann es mehr als 2^32 bit adressieren und PAE compilierte anwendungen laufen auch …
So isses zumindest bei Archlinux(32) … und sorry, hab auf den Kleinen wo nur 32bit lohnt kein Ubuntu und co, also sorry wenn ich nun eine nicht so sehr „mainstream Variante“ referenziere 
die frage die man sich also hier stellen müsste wäre eigentlich : welchen vorteil bringt es , wenn man natives nutzt , die 64bit varianten zu nutzen
Eigentlich ziemlich einfache antwort (zumindest unter windws): man kann theoretisch mehr wie 2^(32-1) bytes adressieren. Ob man die bekommt iss nen anderes Thema.
Nur das ist eigentlich auch der unterschied zwischen 32 und 64 bit system. Auch nen 32 bit System mit entsprechenden AMD/Intel Prozessor konnte schon 64bit instructions ausführen (processor instruction extensions … MMX SSE ) trotzdem warens immer noch nen 32bit Prozessor … heutige Prozessoren sind eh schon lange 64bittig. Und mit entsprechenden Flags / prozessor support übersetzt, benutzen die auch unter 32bit schon längst auch 64bit instructions.
und alle „main“ operationen , also integer operationen, bleiben beim „normalen“ 64bit type Modell 32 bit operationen … und int bleibt 32 bit.
erst wenn man beim compilieren auf das andere modell umschaltet, werden ints zu 64 bit.
Beim 64bit Prozesser muessen die 64bit standard integer instructions „genau so schnell sein“ wie die 32bitter
Das braucht nen 32bit prozessor natürlich nicht.
Standardmäßig werden aber nur die Adressen von 32 auf 64 bit hochgezogen.
Ansonsten betriffts nur die reinrassigen 64bit typen (__int64, long, long long, int64_t, uint64_t … ) aber wer verendet die scho …
Also „normal compiliert“ bleibt ausser der speicheradressierung fast alles beim alten für den prozessor …
Merken tut man da als C++ entwickler effektiv 2 dinge:
32bit/64bit lassen sich ned mixxen, man muss mehr auf compatiblität der libs/dlls aufpassen.
man kann mit dem Speicher mehr rumsauen … wenn man denn hat ^^
Ciao …