NDAleksey, при переходе с Win7 на Win7 x64 я заметил что одна и та-же среда разработки
IntellijIdea стала прожорливее. У меня еще нет точных цифр но опции -Xmx для сборщика
maven, для режима debug и JBoss пришлось увеличить в прибл 1.5 раза.

BlazkowiczmaytonNDAleksey, при переходе с Win7 на Win7 x64 я заметил что одна и та-же среда разработки
IntellijIdea стала прожорливее. У меня еще нет точных цифр но опции -Xmx для сборщика
maven, для режима debug и JBoss пришлось увеличить в прибл 1.5 раза.
x64 требует больше памяти, а для Java так тем более. У меня на x86 монстро-код в идее на 1.5Гб куче шевелится. А у штатовских колег по 4-6 гиг выделено. И какой-то радикальной разницы в производительности не замечаю.
Думаю что тип reference которым оперирует JVM меняет свою разрядность в зависимости
от архитектуры (JRE) и для 64 разрядной модели памяти соответствено увеличивает
физический размер ссылки в heap и permgen. Мы, Java-разработчики долгое время
считаем размер ссылки чем-то эфемерным и неподвластным счёту. Ну... по крайней
мере не учитываем его когда прикидываем на глазок объём структуры данных.

А зря...

Хм... любопытно.

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html Compressed Oops

An "oop", or ordinary object pointer in Java Hotspot parlance, is a managed pointer to an object. An oop is normally the same size as a native machine pointer, which means 64 bits on an LP64 system. On an ILP32 system, maximum heap size is somewhat less than 4 gigabytes, which is insufficient for many applications. On an LP64 system, the heap used by a given program might have to be around 1.5 times larger than when it is run on an ILP32 system. This requirement is due to the expanded size of managed pointers. Memory is inexpensive, but these days bandwidth and cache are in short supply, so significantly increasing the size of the heap and only getting just over the 4 gigabyte limit is undesirable.

Managed pointers in the Java heap point to objects which are aligned on 8-byte address boundaries. Compressed oops represent managed pointers (in many but not all places in the JVM software) as 32-bit object offsets from the 64-bit Java heap base address. Because they're object offsets rather than byte offsets, they can be used to address up to four billion objects (not bytes), or a heap size of up to about 32 gigabytes. To use them, they must be scaled by a factor of 8 and added to the Java heap base address to find the object to which they refer. Object sizes using compressed oops are comparable to those in ILP32 mode.

The term decode is used to express the operation by which a 32-bit compressed oop is converted into a 64-bit native address into the managed heap. The inverse operation is referred to as encoding.

Compressed oops is supported and enabled by default in Java SE 6u23 and later. In Java SE 7, use of compressed oops is the default for 64-bit JVM processes when -Xmx isn't specified and for values of -Xmx less than 32 gigabytes. For JDK 6 before the 6u23 release, use the -XX:+UseCompressedOops flag with the java command to enable the feature.