Почему CONSTANT_Long_info и CONSTANT_Double_info все еще 2?

Question

Когда JVM была изначально разработана, конструкторы имели структуры CONSTANT_Long_info и CONSTANT_Double_info в пуле констант, занимающие 2 записи (предположительно потому, что таким образом вы могли бы индексировать пул констант путем 4-байтового выравнивания или чего-то подобного эти строки).

Однако, согласно спецификации JVM 10, она не была изменена .

Если для его изменения потребуются изменения в большом количестве кода, это будет иметь смысл, поскольку предполагается, что JVM сможет выполнять код, созданный для более старых JVM, но мне кажется, что для этого потребуется очень мало изменений с условным определите, имеете ли вы дело с классом из более ранней версии - единственные случаи, когда это уместно, - это если вы инициализируете константный пул или выполняете итерации по нему, что происходит не очень часто и в любом случае пронизано условными выражениями .

Кроме того, в прошлом были введены гораздо более масштабные изменения, такие как модули Java 9. Итак, почему это все еще так сегодня? Есть ли архитектурная причина, или это просто не стоит никого пока?

Answer 1

Как и в случае большинства изменений с Java 1.1 на Java 11, введение модулей не сильно изменилось, когда дело доходит до формата байт-кода. Это может быть радикально, когда дело доходит до логики приложения или отражения, не для инструментов обработки байтового кода, которые требовали лишь незначительных расширений.

Изменение логики CONSTANT_Long_info и CONSTANT_Double_info будет иметь смысл, только если вы пойдете на более широкую картину, например. также измените тот факт, что long и double принимают две локальные переменные и две записи стека операндов. Тогда вам придется много раз прикасаться к кодовым местам.

Но независимо от того, насколько малы или велики изменения, важным вопросом является то, что вы получаете в обмен? Лучшее чувство не считается. Основной причиной его изменения будет упрощение правил и, следовательно, инструментов обработки байт-кода. Но поскольку этим инструментам потребуются условные выражения, чтобы разрешить все еще существующую обработку файлов более старых классов, это преимущество не будет реализовано. Фактически, с такими изменениями инструменты станут более сложными.

Было бы иначе, если бы вы разработали совершенно новый формат, который все равно требует новых инструментов, например, это был бы вариант для формата JMOD, но именно необходимость разработки нового набора инструментов является причиной, почему этого не произошло, и текущий JMOD - это просто zip-файл, как старые jar-файлы.

Примером счетчика является атрибут StackMapTable , который не имел ограничений на обратную совместимость при разработке и, следовательно, не учитывает записи long и double дважды. Обязанностью инструмента обработки является преобразование этих записей стековой карты в записи стекового фрейма, которые используют два для значений long и double (если мы не говорим о среде, которая выполняет преобразование наоборот).