2009-04-23 7 views
95

Wird Java-Code erstellt und kompiliert gegen ein 32-Bit-JDK in 32-Bit-Byte-Code in einer 64-Bit-JVM? Oder benötigt eine 64-Bit-JVM 64-Bit-Byte-Code?Java-32-Bit-64-Bit-Kompatibilität

Um ein wenig mehr Details zu geben, habe ich Code, der in einer Solaris-Umgebung mit einer 32-Bit-JVM arbeitete, aber jetzt bekomme ich Probleme nach dem Upgrade von JDK und Weblogic Server auf 64-Bit.

+3

bitte klären Sie "Probleme". –

+0

Ich habe ein ähnliches Problem - Bereitstellung einer Spring-App auf einem 64-Bit-Weblogic-Server. Wir erhalten verschiedene nicht gefundene Ausnahmen und andere nicht hilfreiche Fehler. Darüber hinaus wird es auf einigen 64-Bit-Computern bereitgestellt und ausgeführt, jedoch nicht auf anderen. Wir können jedoch nicht sagen, was anders ist. Hast du das gelöst? – nont

+2

@nont - was auch immer das Problem ist, ist es nicht 32VS64 Bit Compilation. –

Antwort

90

Ja, Java-Bytecode (und Quellcode) ist plattformunabhängig, vorausgesetzt, Sie verwenden plattformunabhängige Bibliotheken. 32 gegen 64 Bit sollte nicht wichtig sein.

+0

Ich stieß darauf, während ich nach einer Frage suchte, die ich hatte. SO führte ich meine Anwendung unter einer 32-Bit-JVM und 64-Bit-native Bibliothek verwendet. Es lief gut. Aber wenn ich meine Anwendung unter einer 64-Bit-JVM ausführe und eine native 32-Bit-Bibliothek verwende, schlägt sie fehl. Wie könnte das möglich sein? Nur neugierig. –

+6

@umangdesai native Bibliotheken sind keine plattformunabhängigen Bibliotheken, daher gilt die Annahme nicht. –

+0

Bedeutet "sollte nicht wichtig", dass mit 32-Bit 'javac' kompilierter Code den mit 64-bit' java' bereitgestellten Speicher ausnutzt? –

11

Ja zur ersten Frage und nein zur zweiten Frage; Es ist eine virtuelle Maschine. Ihre Probleme beziehen sich wahrscheinlich auf nicht spezifizierte Änderungen in der Bibliotheksimplementierung zwischen Versionen. Obwohl es sich beispielsweise um eine Race Condition handeln könnte.

Es gibt einige Reifen, die die VM durchlaufen muss. Bemerkenswerterweise werden Verweise in Klassendateien behandelt, als ob sie den gleichen Platz wie int s auf dem Stapel einnehmen würden. double und long nehmen zwei Referenzsteckplätze auf. Zum Beispiel Felder, es gibt einige Umlagerungen, die die VM normalerweise durchläuft. Dies ist alles (relativ) transparent.

Auch einige 64-Bit-JVMs verwenden "komprimierte Oops". Da Daten auf etwa alle 8 oder 16 Bytes ausgerichtet sind, sind drei oder vier Bits der Adresse nutzlos (obwohl ein "Mark" -Bit für einige Algorithmen gestohlen werden kann). Dies ermöglicht 32-Bit-Adressdaten (daher mit halb so viel Bandbreite und daher schneller), Heap-Größen von 35 oder 36 Bits auf einer 64-Bit-Plattform zu verwenden.

+3

Sie überraschen mich. Ich dachte nicht, dass es so etwas wie 32-Bit-Byte-Code oder 64-Bit-Byte-Code gibt. –

+3

Sie haben Ihre Antwort noch einmal gelesen - sind Sie sicher, dass Sie es nicht nur umgekehrt meinten? (Ja dann nein.) –

+0

+1 zu Jon Skeet. Ich schrieb den gleichen Kommentar, wurde aber weggerufen. –

20

Ich habe versehentlich unsere (große) Anwendung auf einer 64-Bit-VM anstelle einer 32-Bit-VM ausgeführt und erst bemerkt, dass einige externe Bibliotheken (von JNI aufgerufen) fehlgeschlagen sind.

Daten, die auf einer 32-Bit-Plattform serialisiert wurden, wurden auf der 64-Bit-Plattform ohne Probleme eingelesen.

Welche Art von Problemen bekommen Sie? Funktionieren einige Dinge und nicht andere? Hast du versucht, JConsole usw. anzubringen und hast einen Peak um?

Wenn Sie eine sehr große VM haben, können Sie feststellen, dass GC-Probleme in 64 Bit Sie beeinflussen können.

+1

sagst du, dass JNI-Bibliotheken nicht in einer 64-Bit-VM funktionieren, wenn sie 32 Bit sind? –

+0

Sie haben nicht in unseren. Aber es ist eine Weile her, seit ich es versuchte – Fortyrunner

+1

Sie funktionieren nicht. Ein Kollege hatte das gemeldet (was ich misstrauisch fand). Ich fragte mich, ob er auf Solaris lief und dass da irgendeine Art von Thunking vor sich ging. Es war nicht; er hat sich geirrt und läuft unter 32bit. – Fortyrunner

10

Der gesamte Byte-Code ist 8-Bit-basiert. (Deshalb heißt es BYTE-Code) Alle Anweisungen sind ein Vielfaches von 8 Bits. Wir entwickeln auf 32-Bit-Maschinen und betreiben unsere Server mit 64-Bit-JVM.

Können Sie einige Details zu dem Problem angeben, vor dem Sie stehen? Dann können wir Ihnen vielleicht helfen. Sonst würden wir nur raten, was das Problem ist, das Sie haben.

8

Wenn Sie keinen systemeigenen Code haben (Maschinencode für eine bestimmte Arcitechture kompiliert), wird Ihr Code in einer 32-Bit- und 64-Bit-JVM genauso gut ausgeführt.

Beachten Sie jedoch, dass aufgrund der größeren Adressen (32-Bit ist 4 Byte, 64-Bit ist 8 Byte) eine 64-Bit-JVM mehr Speicher benötigt als eine 32-Bit-JVM für die gleiche Aufgabe.

+0

Beachten Sie auch, dass eine 32-Bit-JVM auf einem 64-Bit-System möglicherweise mehr Speicher hat als ein 32-Bit-System. Bit JVM auf einem 32-Bit-System, so könnte es eine interessante Option sein, wenn Sie eine Anwendung "Verwenden Sie ein paar GB Speicher" haben. –

-5

yo wo falsch! Zu diesem Thema habe ich eine Frage an Orakel geschrieben. Die Antwort war.

"Wenn Sie Ihren Code auf einer 32-Bit-Maschine kompilieren, sollte Ihr Code nur auf einem 32-Bit-Prozessor laufen. Wenn Sie Ihren Code auf einer 64-Bit-JVM ausführen möchten, müssen Sie Ihre Klasse Dateien auf einem 64 Bit kompilieren Maschine mit einem 64-Bit-JDK. "

+5

Der [Byte-Code-Format] (http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html) Java-Code wird normalerweise kompiliert, um unabhängig von 32-Bit- oder 64-Bit-Plattformen zu sein. _Die Regeln sind für jeden nativen Code unterschiedlich, aber der Java-Byte-Code ist portabel. _ – McDowell

+4

Ja, sieht aus, als ob derjenige, der bei Oracle war, Ihre Frage entweder falsch verstanden oder nichts über die JVM wusste. –

3

Die Differenz zwischen 32 und 64 Bit wird wichtiger, wenn Sie mit nativen Bibliotheken kommunizieren. 64-Bit-Java kann nicht mit einer 32-Bit-Nicht-Java-DLL (über JNI) verbunden werden.

+5

Sie haben dieser sehr alten Frage nichts Neues gegeben. –

0

Das Java JNI erfordert Betriebssystembibliotheken mit der gleichen "Bittigkeit" wie die JVM. Wenn Sie versuchen, etwas aufzubauen, das beispielsweise von IESHIMS.DLL abhängt (lebt in% ProgramFiles% Internet Explorer), müssen Sie die 32-Bit-Version verwenden, wenn Ihre JVM 32-Bit ist, die 64-Bit-Version, wenn Ihre JVM 64-Bit ist. Ebenso für andere Plattformen.

Abgesehen davon sollten Sie alle eingestellt sein. Der generierte Java-Bytecode ist s/b gleich.

Beachten Sie, dass Sie den 64-Bit-Java-Compiler für größere Projekte verwenden sollten, da er mehr Speicher adressieren kann.