64 bit jvm даст прирост производительности даже для приложений с размером кучи менее 4Gb даром.
С чего бы это вдруг ?
Миф #1. 64битные указатели в 64х битной jvm. Это не совсем так. Или скажем - не совсем всегда так.
Начиная с java6u23 по-умолчанию включена опция -XX:+UseCompressedOops, которая позволяет использовать младшие 32 бита указателя, если все старшие нулевые биты, и чуть более хитрая логика в другом случае.
Дальше - больше. При использовании jvm с размером кучи < 4Gb будут использованы только 32битные указатели без какой-либо проверки и математики на вычисление диапозона указателя.
Миф #2. Но это уже не миф, а реальность.
Используя 32х битное приложение на 64х битной платформе доступа адресация, регистры и т.п только в режиме 32х битной совместимости. В то время как само кол-во регистров (TBD: тут следует найти и уточнить их для intel) и больше (в штуках), и доступны 64х битные регистры.
В качестве подопытного кролика, который был у меня под рукой:
основанный на disrupor gflogger, с включённой опцией один байт на символ (что дало большую пропускную способность, чем держать unicode char).
Т.о. прирост составил ~15%.
3 комментария:
Володь, а можешь пояснить, что такое 32х битное приложение на Java? А то у меня тут когнитивный дисонанс, так как насколько я помню, типы на Java фиксированной длины. Или я что-то упустил?
@Nodir
Имел в виду 32х битную jvm
Аааа, спасибо. А то меня замкнуло. Может я что-то упустил, занимаясь встроенными системами и младшим братом JavaCard.
Отправить комментарий