openjdk и флаги компилятора

Очень интересно, как может быть связана оптимизация по размеру кода самого компилятора с тем кодом, который будет производить уже он сам?

Не важно, какого размера код (файл .class), а важно, сколько памяти будут занимать объекты, когда они создадутся. Ну, может, создается 100500 стандартных java-объектов, каждый из которых будет меньше занимать (хотя, сомнительно, т.к. размеры по крайней мере стандартных типов типа Integer не зависят от компилятора).

Очень сомнительно, размер объекта и так достаточно мал и оптимизирован.

Поясню ещё раз: то, с какими параметрами создавать объекты при загрузке байт-кода, определяется логикой VJM, а не клчами, с которыми она была откомпилирована. Эти ключи влияют только на размер кода самой VJM.

Размер зависит от параметров запуска самой программы. Для экономии смотрите -client (безопасно) или -Xmx (может упасть если переборщить)

Для экономии смотрите -client (безопасно) или -Xmx (может упасть если переборщить)

вы переотмечали, похоже, дорогой мой.

Может таки переотмечал, но хочу узнать что не так все же

1) -client ничего не далает в 64-х битной яве

2) -client никак не влияет на размер одного объекта, меньше памяти он жрет за счет более простого jit-компилятора.

3) -Xmx никак не влияет на размер одного объекта, это просто ограничение на количество используемой памяти.

итого первая опция никак не влияет на размер, занятый объектами - только на размер, занятый кодом, вторая - не влияет на размер объектов, которые в данный момент используются программой, влияет только на размер объектов, не собранных GC (потому что именно его и ограничивает)

-client ничего не далает в 64-х битной яве

Ну тогда ничего и не поделаешь

-client никак не влияет на размер одного объекта, меньше памяти он жрет за счет более простого jit-компилятора.

-Xmx никак не влияет на размер одного объекта, это просто ограничение на количество используемой памяти.

Верно, никогда и не говорил ничего о одном обьекте. Просто java разгуляется на меньшем поле

На самом деле, она у меня одинаково разгуливается на разных -Xmx. Просто если его значение слишком мало, падает.

В общем, ничего не поделаешь - это ява

Если она обьективно не влезла, то упала. А если mx большой, то она просто дольше будет не собирать мусор. Сжать можно много софта по настоящему за счет более частого gc

А, так вот почему у меня нет разницы - я принудительно вызываю gc в определенные моменты, когда кучи мусора должны образовываться...

Не делайте так

На 64х битных системах можно менять размер используемых указателей с помощью опции -XX:+UseCompressedOops.

Не делайте так

А чем чревато? Ну, кроме потери производительности (это происходит в среднем раз в 20 минут, так что вроде не страшно)

full gc достаточно дорогостоящее удовольствие. А если у вас обычный билд openjdk, то gc там и так работает и собирает (по крайней мере должен) все без вашего вмешаетльства.