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