Вы бы с ограничениями архитектуры AMD64 ознакомились, что ли. Хотя бы для приличия.

А во-вторых - виртуальное адресное пространство далеко не бесплатно. В "прямой" схеме x86-архитектуры каждые полные или неполные два мегабайта линейного (виртуального) адресного пространства требуют одну физическую (4КБ) страницу в таблице страниц диспетчера виртуальной памяти. Большие страницы не рассматриваем - это отдельный класс виртуальной памяти и он далеко не универсальный.
В худшем случае "разреженного" выделения одна (виртуальная) страница данных (приложения) потребует одной (физической) страницы для данных VMM. Плюсом идёт то, что у каждого процесса - собственная карта виртуальной памяти, что ещё больше увеличивает расходы на управление (виртуальным) адресным пространством.
Фрагментировать "не такое большое" (по факту) адресное пространство - вполне реально.

JVM всегда требует сплошного адресного пространства, даже если конкретное приложение могло бы обойтись "отдельными кусками".
Насколько я понимаю, решаться это будет рамках нового API для работы с внешней памятью: JEP 370: Foreign-Memory Access API (Incubator) ( Java 14 ).

Априори JVM не знает какие массивы будет выделять приложение. Создание объекта "массив", напомню - функция JVM.
Возврат неиспользуемой памяти операционной системе появился далеко не сразу и далеко не во всех сборщиках мусора.
Отказ запускаться с фрагментированной кучей сразу - вполне разумное решение. Со своими недостатками, но это можно сказать о большинстве практичных общецелевых технических решениях.

Не физической памяти, а линейно-адресуемого (виртуального) адресного пространства , доступного процессу.
Для физической памяти нет понятия фрагментации - страницы отображаются в линейное адресное пространство процесса как богVMM положит.
Исключение - драйвера, работающие с устройствами ввода-вывода и устройствами, отображающими свою память в (физическое) адресное пространство процессора, "но это уже совсем другая история".

Одним куском, Карл. Одним куском не мог.
Как говорил великий комбинатор: "Я бы взял частями, но мне нужно сразу".

Оно и такое и такое.
Процесс может запрашивать и глобальные объекты, которые могут отображаться на одинаковые адреса в пространстве всех процессов. Глобальные объекты могут, наверное, и неявно создаваться операционной системой.
Одинаковые линейные адреса глобальных объектов для всех процессов могут назначаться по соображениям, например, эффективности и скорости.

... и получим облом задолго до исчерпания 2ГБ лимита. В худшем случае я мог выделить JVM менее 1000MiB, в лучшем - в пределах 1700MiB.

P.S.
Не надо сравнивать 32- и 64-разрядные системы напрямую - сохранение (ограниченной) обратной совместимости оно тоже не бесплатное.
Ну и лобовые экстаполяции - очень вредно: появляются дебильные темы про векторы из триллиона элементов и такие же вопросы про эффективность их кэширования.

Про физическую память сразу забудьте - на прикладном уровне она вас, в целом, не касаетсяТ.к. "маппинг" осуществляется с гранулярностью одна страница и проблемы "одним куском" быть не должно в принципе IMHO"Особо принципиальные" будут работать сильно медленнее. Причём на самых критичных ко времени операциях типа IPC.
Просто потому, что "пойдя на принцип" не получится задействовать глобальные страницы, которые только и могут "пережить" смену карты памяти при переключении с одного процесса на другой.

Я ставил для исполняемых файлов JRE флаг "Lagre Address Aware" - это меняет выделение памяти 32-разрядному процессу в 64-разрядной OS.
Не факт, что произвольный 32-разрядный бинарь будет правильно работать с этим флагом, когда реально "залезет" за второй гигабайт, но, в теории, можно запросить почти 4ГБ.

В 32-разрядной винде - да. В 64-разрядной винде не требуется резервировать "минимум 1ГБ" в адресном пространстве 32-разрядного процесса.