32-розрядна сумісність Java проти 64-бітної сумісності

Чи буде вбудований і компільований код Java проти 32-розрядного JDK в 32-розрядний байт-код в 64-розрядному JVM? Або 64-розрядна JVM вимагає 64-розрядного байт-коду?

Щоб детальніше розповісти, у мене є код, який працював у середовищі Solaris під керуванням 32-розрядного JVM, але тепер у мене виникають проблеми після оновлення JDK та Weblogic Server до 64-розрядних.

Так, байт-код Java (та вихідний код) не залежить від платформи, якщо використовуватись незалежними від платформи бібліотеками. 32 проти 64 біт не має значення.

Я випадково запустив нашу (велику) програму на 64-бітовому ВМ, а не на 32-бітовому ВМ, і не помітив, поки деякі зовнішні бібліотеки (звані JNI) почали виходити з ладу.

Дані, серіалізовані на 32-бітній платформі, зачитувалися на 64-бітній платформі, без проблем.

Які проблеми ви отримуєте? Чи працюють деякі речі, а не інші? Ви пробували приєднати JConsole тощо і маєте пік навколо?

Якщо у вас дуже велика віртуальна машина, ви можете виявити, що проблеми з GC у 64 бітах можуть вплинути на вас.

Так на перше питання і ні на друге питання; це віртуальна машина. Можливо, ваші проблеми пов'язані з невстановленими змінами в реалізації бібліотеки між версіями. Хоча це може бути, скажімо, умова гонки.

Є кілька обручів, через які VM має пройти. Особливо посилання обробляються у файлах класу так, ніби вони займають таке ж місце, як і ints у стеці. 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-розрядним dll без Java (через JNI)

Додайте параметр, як показано нижче, у конфігурації під час створення EXE

http://www.technimi.com/index.php?do=/group/java/forum/building-an-exe-using-launch4j-for-32-bit-jvm/

Я сподіваюся, що це допомагає.

Дякую...

/ яв

Для Java JNI потрібні бібліотеки ОС такої ж «побитості», як і JVM. Якщо ви намагаєтесь побудувати щось, що залежить, наприклад, від IESHIMS.DLL (живе у% ProgramFiles% \ Internet Explorer), вам потрібно взяти 32-бітну версію, коли ваш JVM - 32-бітний, 64-бітну версію, коли ваш JVM - 64-бітний. Так само і для інших платформ.

Крім цього, у вас має бути все налаштовано. Створений байт-код Java s / b те саме.

Зауважте, що для великих проектів слід використовувати 64-бітний компілятор Java, оскільки він може зайняти більше пам'яті.

йо, де не так! До цієї теми я написав запитання до oracle. Відповідь була.

"Якщо ви компілюєте свій код на 32-бітній машині, ваш код повинен працювати лише на 32-бітовому процесорі. Якщо ви хочете запустити свій код на 64-бітовому JVM, вам слід скласти файли класу на 64-бітній машині за допомогою 64 -Біт JDK. "