Java 32-битная и 64-битная совместимость
Будет ли код Java, скомпилированный и скомпилированный из 32-битного JDK в 32-битный байт-код, работать в 64-битной JVM? Или 64-разрядная JVM требует 64-разрядного байтового кода?
Чтобы немного подробнее, у меня есть код, который работал в среде Solaris с 32-битной JVM, но теперь у меня возникают проблемы после обновления JDK и Weblogic Server до 64-битной.
9 ответов
Да, байт-код Java (и исходный код) не зависит от платформы, при условии, что вы используете независимые от платформы библиотеки. 32 против 64 бит не должно иметь значения.
Я случайно запустил наше (большое) приложение на 64-битной виртуальной машине, а не на 32-битной виртуальной машине, и не заметил, пока некоторые внешние библиотеки (называемые JNI) не начали работать.
Данные, сериализованные на 32-битной платформе, считывались на 64-битной платформе без каких-либо проблем.
Какие проблемы вы получаете? Некоторые вещи работают, а другие нет? Вы пытались подключить JConsole и т. Д., И у вас есть пик?
Если у вас очень большая виртуальная машина, вы можете обнаружить, что проблемы с GC в 64-битной среде могут вас затронуть.
Да на первый вопрос и нет на второй вопрос; это виртуальная машина. Ваши проблемы, вероятно, связаны с неуказанными изменениями в реализации библиотеки между версиями. Хотя это может быть, скажем, состояние гонки.
Есть некоторые проблемы, через которые должна пройти виртуальная машина. Примечательно, что ссылки обрабатываются в файлах классов, как если бы они занимали то же место, что и intв стеке. double а также long занять два контрольных слота. Например, для полей есть какая-то перестановка, через которую обычно проходит ВМ. Это все сделано (относительно) прозрачно.
Также некоторые 64-битные JVM используют "сжатый упс". Поскольку данные выровнены примерно каждые 8 или 16 байтов, три или четыре бита адреса бесполезны (хотя для некоторых алгоритмов бит "метки" может быть украден). Это позволяет 32-разрядным адресным данным (следовательно, использовать вдвое меньшую пропускную способность и, следовательно, быстрее) использовать размеры кучи 35- или 36-разрядных на 64-разрядной платформе.
Весь байт-код основан на 8 битах. (Вот почему он называется кодом BYTE). Все инструкции кратны 8-битному размеру. Мы разрабатываем на 32-битных машинах и запускаем наши серверы с 64-битной JVM.
Не могли бы вы рассказать подробнее о проблеме, с которой вы столкнулись? Тогда у нас может быть шанс помочь вам. В противном случае мы бы просто догадались, в чем проблема.
Если у вас нет нативного кода (машинный код, скомпилированный для конкретной архитектуры), ваш код будет одинаково хорошо работать в 32-битной и 64-битной JVM.
Однако обратите внимание, что из-за больших адресов (32-разрядный - 4 байта, 64-разрядный - 8 байтов) 64-разрядная JVM потребует больше памяти, чем 32-разрядная JVM для той же задачи.
Разница между 32-разрядной и 64-разрядной системами становится все более важной, если вы взаимодействуете с собственными библиотеками. 64-битная Java не сможет взаимодействовать с 32-битной не-Java dll (через JNI)
Добавьте параметр, как показано ниже в вас в конфигурации при создании exe
Я надеюсь, что это помогает.
Спасибо...
/ яв
Java JNI требует от ОС библиотек той же "битности", что и у JVM. Если вы пытаетесь создать что-то, что зависит, например, от IESHIMS.DLL (находится в%ProgramFiles%\Internet Explorer), вам нужно взять 32-битную версию, когда ваша JVM является 32-битной, 64-битную версию, когда ваша JVM является 64-битной. Аналогично для других платформ.
Кроме того, у вас должно быть все готово. Сгенерированный байт-код Java с / б одинаков.
Обратите внимание, что вы должны использовать 64-битный Java-компилятор для больших проектов, потому что он может адресовать больше памяти.
Ты не прав! На эту тему я написал вопрос оракулу. Ответ был.
"Если вы компилируете свой код на 32-битной машине, ваш код должен работать только на 32-битном процессоре. Если вы хотите запустить свой код на 64-битной JVM, вы должны скомпилировать файлы класса на 64-битной машине с использованием 64-битной машины". -Бит JDK."