JEP 503: Remove the 32-bit x86 Port

Аннотация

Удалить исходный код и поддержку сборки для 32-битного порта x86. Этот порт получил статус Deprecated for Removal (устаревший, будет удалён) в JDK 24 (JEP 501) с прямым намерением удалить его в одном из будущих выпусков.

Цели

• Избавить новые возможности, которым нужна платформенно-зависимая поддержка, от необходимости реализовывать запасные варианты для 32-битной x86.

• Удалить все ветви кода, которые относятся только к 32-битной x86.

• Упростить инфраструктуру сборки и тестирования JDK.

Что не является целью

• Удаление или изменение 32-битной поддержки для любых других архитектур не является целью.

• Удаление 32-битного порта x86 из прошлых выпусков не является целью.

Мотивация

Как отмечалось, когда мы перевели этот порт в статус Deprecated (устаревший) в JEP 501:

Затраты на сопровождение этого порта перевешивают пользу. Поддержание паритета с новыми возможностями, такими как Loom, Foreign Function & Memory API (FFM), Vector API, позднее раскрытие барьеров GC и т. д., означает большие альтернативные издержки. Если перевести порт в статус Deprecated, а затем удалить его, разработчики OpenJDK смогут ускорить разработку новых возможностей и улучшений.

Описание

Сейчас 32-битный порт x86 ещё можно собрать, хотя он не поддерживается и его хорошая производительность не гарантируется.

Мы найдём и удалим поддержку 32-битной x86 в сборке и в коде. Учитывая сильную связанность 32-битной и 64-битной частей x86-специфичного кода в HotSpot JVM, мы ожидаем, что более глубокая чистка займёт значительное время и будет постоянно вызывать конфликты с непрерывно меняющимся кодом HotSpot. Поэтому мы намерены удалить 32-битный порт x86 в начале цикла разработки JDK 25, а затем провести серию последующих чисток в общем коде, до того как начнут интегрироваться крупные возможности.

Мы изменим систему сборки JDK, чтобы убрать поддержку компиляции на 32-битных платформах x86, а также обновим документацию JDK, чтобы она отражала удаление поддержки 32-битной x86.

Риски и допущения

Здесь применимы исходные риски и допущения из JEP 501:

• В отрасли нет острой потребности в 32-битной x86 с современными JDK — мы исходим из того, что мир x86 окончательно перешёл на 64 бита. Новое оборудование x86, поддерживающее только 32 бита, не выпускается. Оставшиеся 32-битные развёртывания x86 — это наследие. Поддержка в отрасли сократилась в соответствии с этой реальностью. Поддержка Windows 10, последней операционной системы Windows с поддержкой 32-битного режима, закончится (End of Life) в октябре 2025 года, а 32-битный порт x86 для Windows уже удалён из JDK (JEP 479). Debian планирует прекратить поддержку 32-битной x86 в ближайшем будущем.

• Запаса достаточно для безопасного переноса исправлений (backport) в выпуски, которые ещё поддерживают 32-битную x86 — отсутствие порта Linux для 32-битной x86 в основной ветке означает, что перенос исправлений из основной ветки в активно поддерживаемые LTS-выпуски станет сложнее, поскольку их придётся согласовывать с портом Linux для 32-битной x86, который в этих выпусках ещё есть. Мы исходим из того, что большинство старых стеков приложений для Linux на 32-битной x86 всё ещё работают на JDK 8, в который мы переносим исправления нечасто, и это снижает риск. У сопровождающих порта Linux для 32-битной x86 в более новых LTS-выпусках всё равно появится дополнительная работа, чтобы их сборки оставались рабочими.

• Сопровождение других 32-битных портов существенно не затрагивается — Linux на 32-битной x86 служит средством поддерживать корректность кода для 32 бит, что косвенно помогает сопровождению других 32-битных портов, прежде всего ARM32. Мы исходим из того, что сможем и дальше без особого труда сопровождать порт ARM32.

• Запасные варианты можно тестировать отдельно — мы исходим из того, что существующие запасные механизмы, такие как планировщик 1:1 в Loom и запасной компоновщик (fallback linker) в FFM, можно тестировать отдельно, без бремени сопровождения всего порта Linux для 32-битной x86.

Кроме того, мы исходим из того, что JEP 501 достаточно заранее предупредил поставщиков и пользователей, чтобы они продумали пути миграции с 32-битной x86.