Compatibilidade Java de 32 bits vs 64 bits

97

O código Java construído e compilado em um JDK de 32 bits em código de bytes de 32 bits funcionará em uma JVM de 64 bits? Ou uma JVM de 64 bits requer código de bytes de 64 bits?

Para dar mais detalhes, tenho um código que estava funcionando em um ambiente Solaris executando uma JVM de 32 bits, mas agora estou tendo problemas após atualizar o JDK e o Weblogic Server para 64 bits.

java  jvm  64-bit  compatibility  32-bit 
— mshafrir
fonte
3
por favor, esclareça "questões".
— Thorbjørn Ravn Andersen,
Estou tendo um problema semelhante - implantar um aplicativo Spring em um servidor weblogic de 64 bits. Obtemos várias exceções de classe não encontrada e outros erros inúteis. Além disso, ele é implantado e executado em algumas máquinas de 64 bits, mas não em outras. Não podemos dizer o que é diferente, no entanto. Você resolveu isso?
— não
2
@nont - seja qual for o problema, não é uma compilação de 32vs64 bits.
— Stephen C

Respostas:

94

Sim, o bytecode Java (e código-fonte) é independente da plataforma, supondo que você use bibliotecas independentes da plataforma. 32 x 64 bits não devem importar.

— Zifre
fonte
Corri para isso enquanto procurava por uma pergunta que eu tinha. SO eu executei meu aplicativo em um JVM de 32 bits e usei a biblioteca nativa de 64 bits. Funcionou bem. Mas quando executo meu aplicativo em uma JVM de 64 bits e uso a biblioteca nativa de 32 bits, ele falha. Como isso pode ser possível? Apenas curioso.
— Umang Desai
6
As bibliotecas nativas @umangdesai não são bibliotecas independentes de plataforma, portanto, a suposição não é válida.
— Thorbjørn Ravn Andersen
"Não deveria importar" significa que o código compilado com 32 bits javacaproveitará a memória disponibilizada com 64 bits java?
— Marcus Junius Brutus,
1
Se você está se incomodando com isso, tome cuidado com as bibliotecas nativas que foram agrupadas em um jar que funcionam para uma plataforma, mas não para aquela que apresenta problemas. (Se você não tem ideia do que estou me referindo, veja coisas como isto: stackoverflow.com/a/14051512/155631 ).
— Matt S.
21

Eu acidentalmente executei nosso aplicativo (grande) em uma VM de 64 bits em vez de uma VM de 32 bits e não percebi até que algumas bibliotecas externas (chamadas por JNI) começaram a falhar.

Os dados serializados em uma plataforma de 32 bits foram lidos na plataforma de 64 bits sem nenhum problema.

Que tipo de problemas você está tendo? Algumas coisas funcionam e outras não? Você já tentou anexar JConsole etc e tem um pico ao redor?

Se você tiver uma VM muito grande, poderá descobrir que os problemas de GC em 64 bits podem afetá-lo.

— Fortyrunner
fonte
1
você está dizendo que as bibliotecas JNI não funcionarão em uma VM de 64 bits se forem de 32 bits?
— C. Ross
1
Eles não funcionam. Um colega relatou que sim (o que eu achei suspeito - para dizer o mínimo). Eu me perguntei se ele estava rodando no Solaris e se estava acontecendo algum tipo de estrondo. Não havia; ele estava enganado e estava rodando em 32 bits.
— Fortyrunner de
Tive um problema semelhante com uma biblioteca JNI. Não havia compatibilidade entre as bibliotecas de 32 e 64 bits.
— Erick Robertson
Na verdade, suas bibliotecas JNI precisam ser substituídas. Você provavelmente pode apenas baixar a alternativa de 64 bits no site do fornecedor. (Isso funcionou para mim, para todas as bibliotecas JNI que usei).
— bvdb
Essas eram bibliotecas internas e nenhum equivalente de 64 bits estava disponível, então voltar para 32 bits era a ordem do dia.
— Fortyrunner
11

Sim para a primeira pergunta e não para a segunda pergunta; é uma máquina virtual. Seus problemas provavelmente estão relacionados a mudanças não especificadas na implementação da biblioteca entre as versões. Embora possa ser, digamos, uma condição de corrida.

Existem alguns obstáculos pelos quais a VM deve passar. Notavelmente, as referências são tratadas em arquivos de classe como se ocupassem o mesmo espaço que ints na pilha. doublee longocupar dois slots de referência. Por exemplo, campos, há alguns rearranjos pelos quais a VM geralmente passa de qualquer maneira. Tudo isso é feito (relativamente) de forma transparente.

Além disso, alguns JVMs de 64 bits usam "ops compactados". Como os dados são alinhados a cada 8 ou 16 bytes, três ou quatro bits do endereço são inúteis (embora um bit de "marca" possa ser roubado para alguns algoritmos). Isso permite que os dados de endereço de 32 bits (portanto, usando a metade da largura de banda e, portanto, mais rápido) usem tamanhos de heap de 35 ou 36 bits em uma plataforma de 64 bits.

— Tom Hawtin - tackline
fonte
3
Você me surpreende. Não pensei que existisse código de bytes de 32 bits ou código de bytes de 64 bits.
— Jon Skeet
3
Relendo sua resposta - você tem certeza de que não quis dizer apenas o contrário? (Sim, então não.)
— Jon Skeet
+1 para Jon Skeet. Eu estava escrevendo o mesmo comentário, mas fui chamado.
— Michael Myers
Eu quis dizer não, então sim, mas com as perguntas ao contrário. Reverti uma edição e editei (e coloquei um pouco mais de informações).
— Tom Hawtin - tackline
4
@Jon Skeet: não há bytecode de 32 e 64 bits, mas quando JITed os ponteiros na JVM são (geralmente) de 32 ou 64 bits, dependendo da plataforma. E com OOPS compactado, eles podem usar ponteiros de 32 bits em muitos lugares, até mesmo em JVMs de 64 bits. Isso economiza um pouco de memória e aumenta a localidade do código, resultando em maior velocidade.
— Joachim Sauer
9

Todo o código de byte é baseado em 8 bits. (É por isso que é chamado de código BYTE) Todas as instruções são múltiplos de 8 bits de tamanho. Desenvolvemos em máquinas de 32 bits e executamos nossos servidores com JVM de 64 bits.

Você poderia dar alguns detalhes do problema que está enfrentando? Então, podemos ter a chance de ajudá-lo. Caso contrário, estaríamos apenas adivinhando qual é o problema que você está tendo.

— Peter Lawrey
fonte
8

A menos que você tenha código nativo (código de máquina compilado para uma arquitetura específica), seu código será executado igualmente bem em uma JVM de 32 bits e 64 bits.

Observe, entretanto, que devido aos endereços maiores (32 bits são 4 bytes, 64 bits são 8 bytes), uma JVM de 64 bits exigirá mais memória do que uma JVM de 32 bits para a mesma tarefa.

— Thorbjørn Ravn Andersen
fonte
Observe também que uma JVM de 32 bits em um sistema de 64 bits pode ter mais memória disponível do que uma JVM de 32 bits em um sistema de 32 bits, portanto, pode ser uma opção interessante se você tiver um "uso de alguns GB de memória " inscrição.
— Thorbjørn Ravn Andersen
3

A diferença de 32 bits versus 64 bits se torna mais importante quando você faz interface com bibliotecas nativas. Java de 64 bits não será capaz de fazer interface com uma DLL não Java de 32 bits (via JNI)

— John Thomas
fonte
5
Você não forneceu nada de novo para esta questão tão antiga.
— Austin Henley,
0

O Java JNI requer bibliotecas do sistema operacional da mesma "bittiness" que o JVM. Se você tentar construir algo que dependa, por exemplo, de IESHIMS.DLL (reside em% ProgramFiles% \ Internet Explorer), você precisará obter a versão de 32 bits quando sua JVM é de 32 bits, a versão de 64 bits quando sua JVM é de 64 bits. Da mesma forma para outras plataformas.

Além disso, você deve estar pronto. O bytecode Java gerado s / b é o mesmo.

Observe que você deve usar o compilador Java de 64 bits para projetos maiores porque ele pode endereçar mais memória.

— o carpa
fonte
-5

yo onde errado! Para este tema escrevi uma pergunta ao oracle. A resposta foi.

"Se você compilar seu código em uma máquina de 32 bits, ele só deve ser executado em um processador de 32 bits. Se quiser executar seu código em uma JVM de 64 bits, você deve compilar seus arquivos de classe em uma máquina de 64 bits usando uma máquina de 64 -Bit JDK. "

— elayer
fonte
5
O formato do código de byte em que o código Java é geralmente compilado é o mesmo, independentemente das plataformas de 32 ou 64 bits. As regras são diferentes para qualquer código nativo, mas o código de bytes Java é portátil.
— McDowell
4
Sim, parece que quem estava respondendo à sua pergunta na Oracle entendeu mal ou não sabia nada sobre o JVM.
— Paŭlo Ebermann
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.