Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Речь шла про общее ограничение на доступную память в x32 (без хаков типа PAE), а не про какие-то ограничения индексов массивов в Java в x64.
EP>·>Видимо я что-то не понял, но речь про байткод была. Если пишешь на java, то запускается именно байткод, а там только ограничение связанное с типом индекса массива. Битность физической платформы роли не играет
EP>Играет. На x32 больше 2-4 GiB откусить не получится (без хаков типа PAE).
Понятно, но это не связано с байткодом.

EP>·>Т.е. ограничение 2млрд элементов (не байтов!) в jvm есть только на размеры массивов, а не на общий размер доступной памяти, т.е. с размером адресного пространства и битностью платформы напрямую не связано (связано лишь только существованием осмысленной реалзиации vm).
EP>Ещё раз. Речь про ограничение адресного пространства в x32. Те ограничения Java о которых ты говоришь накладываются уже поверх ограничений адресного пространства — не создашь ты массив с 2мдрд int'ов на x32
EP>А то что у Java проблема с созданием массива в 8млрд байт на x64 — это ортогонально
При наличии поддержки в vm — создашь, теоретически ограничений нет. Хотя на практике, насколько я знаю, такой имплементации vm никто не делал, т.к. бессмысленно, проще взять 64-битное железо. А так я слыхал о реализациях jvm для 16 или даже 8-битных процов.
Были ещё такие проекты, которые позволяли запускать приложение в как бы distributed vm — т.е. код реально выполнялся на множестве машин, имея объединённое адресное пространство. Но не прижилось, как и все эти EE-всемогутеры, эти универсальные решения менее эффективны, чем архитектура хорошо заточенная под конкретную задачу.