Java является Big Endian, как она обрабатывает процессоры с прямым порядком байтов при сохранении производительности? Выполняет ли JVM (OpenJDK, OpenJ9 и т. д.) какие-либо специальные оптимизации для поддержания производительности, например выборочное использование Big Endian в особой ситуации на платформах Little Endian? Существует ли специальная обработка порядка следования байтов при доступе к байтовым буферам, вызове собственного кода, записи в ввод-вывод или доступе к изменчивым переменным? Как Java меняет порядок байтов в архитектурах с прямым порядком байтов? В какой момент или операция (загрузка, сохранение, вычисление, регистры, кеш, память и т. д.) порядок следования байтов изменяется? Какой штраф производительности это будет иметь?
Java является Big Endian, как она обрабатывает процессоры с прямым порядком байтов при сохранении производительности?
Java не является обратным порядком байтов. В тех немногих местах в библиотеке времени выполнения Java, где Endianness даже проблема, API использует Big Endian, но он всегда хорошо документирован, а некоторые API позволяют указать желаемый Endianness.
Выполняет ли JVM (OpenJDK, OpenJ9 и т. д.) какие-либо специальные оптимизации для поддержания производительности, например выборочное использование Big Endian в особой ситуации на платформах Little Endian?
Нет, JVM использует собственный Endianness.
Существует ли специальная обработка порядка следования байтов при доступе к байтовым буферам, вызове собственного кода, записи в ввод-вывод или доступе к изменчивым переменным?
Да, Нет, Да и Нет.
Поскольку JVM использует собственный порядок байтов, для вызова собственного кода или доступа к изменчивым переменным не требуется никакой обработки. Порядок байтов имеет значение только при (де)сериализации в/из байтов, например. при доступе к ByteBuffers или записи в IO.
Как Java меняет порядок байтов в архитектурах с прямым порядком байтов?
Точно так же вы бы изменили Endianness в любом месте, он меняет местами байты или читает/записывает байты в соответствующем порядке.
В какой момент или операция (загрузка, сохранение, вычисление, регистры, кеш, память и т. д.) порядок следования байтов изменяется?
Это не так, поскольку JVM использует родной Endianness. Endianness применяется только тогда, когда собственное значение преобразуется в/из байтов. Ни в какой другой момент времени Endianness не имеет значения.
Какой штраф производительности это будет иметь?
Нет, так как он ничего не делает.
Спасибо за ответ. Этот вопрос и ответ: Endianness виртуальной машины Java говорит, что JVM является Big Endian. В комментарии говорится, что порядковый номер поддерживается как POV.
Также Спецификация виртуальной машины Java, Java SE 15 Edition, раздел 2.11 говорит: The number and size of the operands are determined by the opcode. If an operand is more than one byte in size, then it is stored in big-endian order - high-order byte first. For example, an unsigned 16-bit index into the local variables is stored as two unsigned bytes, byte1 and byte2, such that its value is (byte1 << 8) | byte2.
Также Спецификация виртуальной машины Java, Java SE 15 Edition, Глава 4: Формат файла класса говорит: A class file consists of a stream of 8-bit bytes. 16-bit and 32-bit quantities are constructed by reading in two and four consecutive 8-bit bytes, respectively. Multibyte data items are always stored in big-endian order, where the high bytes come first. This chapter defines the data types u1, u2, and u4 to represent an unsigned one-, two-, or four-byte quantity, respectively.
Если данные хранятся в собственном порядке, что означает вышеизложенное? Я пытаюсь понять это.
Класс-файл всегда с обратным порядком байтов (пришлось выбрать 1 вариант, потому что он должен работать без изменений на всех платформах); но JVM использует порядок байтов платформы и должен выполнять преобразования только при чтении байтов из источников (например, файлов классов), которые могут иметь или не иметь разные порядковые номера.
@SumindaSirinathS.Dharmasena Существует большая разница между байтами, хранящимися в файле байт-кода (.class
), и тем, как данные хранятся в памяти работающей JVM. Все ваши комментарии, а также принятый ответ в первой ссылке, которую вы прокомментировали, касаются файла байт-кода. Ваш вопрос касается JVM (виртуальная машина Java), и именно на это направлен этот ответ.
Так что просто уточнить. (1) Байт-код/код операции + данные в файлах классов имеют обратный порядок байтов. (2) Byte-Code/Opcodes в памяти имеют обратный порядок байтов, в то время как данные являются порядковыми номерами платформы. (3) IO снова является Big-Endian по умолчанию с возможностью изменить его в некоторых случаях, например, в буферах?
@SumindaSirinathS.Dharmasena Правильно, за исключением: 2) «Байт-код/коды операций в памяти» неполные, поскольку они могут быть преобразованы в собственные инструкции ЦП с помощью JIT для повышения производительности. Даже без JIT JVM может хранить байт-код/код операции иначе, чем в файле байт-кода. Это все внутреннее, и JVM может делать все, что захочет.
Java не имеет порядка следования байтов как такового. Файлы классов имеют порядок байтов, но это просто кодировка, и из них легко декодировать целые числа независимо от порядка байтов; то же самое верно даже для многих более эзотерических форматов. Целое число в регистре просто сохраняется как этот регистр, а типизированные массивы не позволяют преобразовать их в байты.