Compatibilità Java a 32 bit rispetto a 64 bit

97

Il codice Java creato e compilato su un JDK a 32 bit in un codice a 32 bit di byte funzionerà in una JVM a 64 bit? Oppure una JVM a 64 bit richiede un codice byte a 64 bit?

Per fornire un po 'più di dettagli, ho del codice che funzionava in un ambiente Solaris con una JVM a 32 bit, ma ora riscontro problemi dopo aver aggiornato JDK e Weblogic Server a 64 bit.

java  jvm  64-bit  compatibility  32-bit 
— mshafrir
fonte
3
si prega di chiarire "problemi".
— Thorbjørn Ravn Andersen
Sto riscontrando un problema simile: distribuzione di un'app primaverile su un server weblogic a 64 bit. Otteniamo varie eccezioni di classe non trovata e altri errori inutili. Inoltre, si distribuisce e funziona su alcune macchine a 64 bit, ma non su altre. Tuttavia, non possiamo dire cosa sia diverso. Hai risolto questo problema?
— fino al
2
@nont - qualunque sia il problema, non è una compilazione a 32 contro 64 bit.
— Stephen C

Risposte:

94

Sì, il bytecode Java (e il codice sorgente) è indipendente dalla piattaforma, presupponendo che si utilizzino librerie indipendenti dalla piattaforma. 32 contro 64 bit non dovrebbero avere importanza.

— Zifre
fonte
Mi sono imbattuto in questo mentre cercavo una domanda che avevo. Quindi ho eseguito la mia applicazione con una JVM a 32 bit e ho utilizzato la libreria nativa a 64 bit. Ha funzionato bene. Ma quando eseguo la mia applicazione con una JVM a 64 bit e utilizzo la libreria nativa a 32 bit, non riesce. Come potrebbe essere possibile? Solo curioso.
— Umang Desai
6
Le librerie native di @umangdesai non sono librerie indipendenti dalla piattaforma, quindi l'assunto non è valido.
— Thorbjørn Ravn Andersen
"Non dovrebbe importare" significa che il codice compilato a 32 bit javacsfrutterà la memoria resa disponibile a 64 bit java?
— Marcus Junius Brutus
1
Se sei punto su questo, fai attenzione alle librerie native che sono state raggruppate in un vaso che funziona per una piattaforma, ma non per quella che ti dà problemi. (Se non hai idea di cosa mi riferisco, guarda cose come questa: stackoverflow.com/a/14051512/155631 ).
— Matt S.
21

Ho eseguito accidentalmente la nostra applicazione (di grandi dimensioni) su una VM a 64 bit anziché su una VM a 32 bit e non me ne sono accorto fino a quando alcune librerie esterne (chiamate da JNI) hanno iniziato a fallire.

I dati serializzati su una piattaforma a 32 bit sono stati letti sulla piattaforma a 64 bit senza alcun problema.

Che tipo di problemi stai riscontrando? Alcune cose funzionano e non altre? Hai provato ad collegare JConsole ecc. E hai avuto un picco in giro?

Se hai una VM molto grande, potresti scoprire che i problemi di GC a 64 bit possono interessarti.

— Fortyrunner
fonte
1
stai dicendo che le librerie JNI non funzioneranno in una VM a 64 bit se sono a 32 bit?
— C. Ross
1
Non funzionano. Un collega aveva riferito di averlo fatto (cosa che ho trovato sospetta, per non dire altro). Mi chiedevo se stesse girando su Solaris e se fosse in corso una sorta di thunk. Non c'era; si era sbagliato e funzionava sotto i 32 bit.
— Fortyrunner
Ho avuto un problema simile con una libreria JNI. Non c'era compatibilità tra le librerie a 32 bit e quelle a 64 bit.
— Erick Robertson
In effetti, le tue librerie JNI devono essere sostituite. Probabilmente puoi semplicemente scaricare l'alternativa a 64 bit dal sito Web del fornitore. (Questo ha fatto il trucco per me, per tutte le librerie JNI che ho usato).
— bvdb
Queste erano librerie interne e non era disponibile alcun equivalente a 64 bit, quindi tornare a 32 bit era all'ordine del giorno.
— Fortyrunner
11

Sì alla prima domanda e no alla seconda; è una macchina virtuale. I tuoi problemi sono probabilmente legati a modifiche non specificate nell'implementazione della libreria tra le versioni. Anche se potrebbe essere, diciamo, una condizione di gara.

Ci sono alcuni ostacoli che la VM deve superare. In particolare, i riferimenti vengono trattati nei file di classe come se occupassero lo stesso spazio di ints nello stack. doublee longoccupano due slot di riferimento. Ad esempio, i campi, c'è qualche riorganizzazione che la VM di solito subisce comunque. Tutto questo viene fatto (relativamente) in modo trasparente.

Inoltre, alcune JVM a 64 bit utilizzano "oops compresso". Poiché i dati sono allineati a circa ogni 8 o 16 byte, tre o quattro bit dell'indirizzo sono inutili (sebbene un bit "mark" possa essere rubato per alcuni algoritmi). Ciò consente ai dati di indirizzo a 32 bit (quindi utilizzando la metà della larghezza di banda, e quindi più veloce) di utilizzare dimensioni di heap di 35 o 36 bit su una piattaforma a 64 bit.

— Tom Hawtin - tackline
fonte
3
Mi sorprendi. Non pensavo esistesse qualcosa come il codice a 32 bit o il codice a 64 bit.
— Jon Skeet
3
Rileggendo la tua risposta - sei sicuro di non aver inteso semplicemente il contrario? (Sì, poi no.)
— Jon Skeet,
+1 a Jon Skeet. Stavo scrivendo lo stesso commento ma sono stato chiamato.
— Michael Myers
Volevo dire no e poi sì, ma con le domande il contrario. Ho annullato una modifica e modificato (e inserito un po 'più di informazioni).
— Tom Hawtin - tackline
4
@ Jon Skeet: non esiste un bytecode a 32 e 64 bit, ma quando viene eseguito il JIT i puntatori nella JVM sono (di solito) a 32 o 64 bit, a seconda della piattaforma. E con OOPS compresso possono utilizzare puntatori a 32 bit in molti posti, anche su JVM a 64 bit. Ciò consente di risparmiare un bel po 'di memoria e aumenta la località del codice, portando così a una maggiore velocità.
— Joachim Sauer
9

Tutto il codice byte è basato su 8 bit. (Ecco perché si chiama codice BYTE) Tutte le istruzioni sono un multiplo di 8 bit. Sviluppiamo su macchine a 32 bit ed eseguiamo i nostri server con JVM a 64 bit.

Puoi fornire qualche dettaglio del problema che stai affrontando? Allora potremmo avere la possibilità di aiutarti. Altrimenti indovineremmo solo qual è il problema che stai riscontrando.

— Peter Lawrey
fonte
8

A meno che non si disponga di codice nativo (codice macchina compilato per una specifica arcitechture), il codice verrà eseguito altrettanto bene in una JVM a 32 bit e 64 bit.

Si noti, tuttavia, che a causa degli indirizzi più grandi (32 bit è 4 byte, 64 bit è 8 byte) una JVM a 64 bit richiederà più memoria di una JVM a 32 bit per la stessa attività.

— Thorbjørn Ravn Andersen
fonte
Tieni inoltre presente che una JVM a 32 bit su un sistema a 64 bit potrebbe avere più memoria disponibile rispetto a una JVM a 32 bit su un sistema a 32 bit, quindi potrebbe essere un'opzione interessante se hai un "utilizzo di pochi GB di memoria " applicazione.
— Thorbjørn Ravn Andersen
3

La differenza a 32 bit rispetto a 64 bit diventa più importante quando ci si interfaccia con le librerie native. Java a 64 bit non sarà in grado di interfacciarsi con una dll non Java a 32 bit (tramite JNI)

— John Thomas
fonte
5
Non hai fornito nulla di nuovo a questa domanda molto vecchia.
— Austin Henley,
0

Java JNI richiede librerie OS della stessa "bittiness" della JVM. Se tenti di creare qualcosa che dipende, ad esempio, da IESHIMS.DLL (risiede in% ProgramFiles% \ Internet Explorer) devi prendere la versione a 32 bit quando la tua JVM è a 32 bit, la versione a 64 bit quando la tua JVM è a 64 bit. Allo stesso modo per altre piattaforme.

A parte questo, dovresti essere pronto. Il bytecode Java generato s / b lo stesso.

Nota che dovresti usare il compilatore Java a 64 bit per progetti più grandi perché può indirizzare più memoria.

— la carpia
fonte
-5

yo dove sbagliato! Su questo tema ho scritto una domanda a Oracle. La risposta è stata.

"Se si compila il codice su una macchina a 32 bit, il codice deve essere eseguito solo su un processore a 32 bit. Se si desidera eseguire il codice su una JVM a 64 bit, è necessario compilare i file di classe su una macchina a 64 bit utilizzando un -Bit JDK. "

— elayer
fonte
5
Il formato del codice byte in cui viene solitamente compilato il codice Java è lo stesso indipendentemente dalle piattaforme a 32 o 64 bit. Le regole sono diverse per qualsiasi codice nativo ma il codice byte Java è portabile.
— McDowell
4
Sì, sembra che chiunque in Oracle abbia risposto alla tua domanda l'ha frainteso o non sapeva nulla della JVM.
— Paŭlo Ebermann
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.