My understanding as far as 64 bit Java is concerned is that the JVM is
available in 64 bit versions for Solaris, Linux, and Windows - typically
for x64 (64 bit x86 processor) architecture. My home PC runs Windows XP
64 bit edition, and the 64 bit JVM with no problems. OFBiz even fires
up and runs fine on it. I would believe that the 64 bit JVM would have
a few advantages over the 64 bit version - not in terms of memory
consumption (and the assertion that a 64 bit system will use double the
memory is incorrect*) - but in terms of actual instructions needed to
accomplish work.
Internally Java has used pretty wide (bitwise) representations of
primitive data types. For example a Java "int" is 32 bits on all JVMs.
At the time of it's introduction that was pretty radical as typically a
'C' style "int" was typically 16 bits wide (depending on the vendor of
your compiler). So you can imagine the "book-keeping" the JVM might
have had to do on earlier operating systems and architectures - needing
to use two 16 bit memory locations to store the value of a 32 bit
integer, and also needing to keep track of which two 16 bit values went
together, etc. The Java "long" type is 64 bits wide. Up until recently
this has meant that the JVM has had to provide "emulation" in a manner
similar to that described for 32 bit values on older systems for 64 bit
values. No longer. A 64 bit JVM should be using native operations
capable of 64 bit wide operands to handle 64 bit values.
* as to why 64 bit processors don't suddenly see 1/2 the memory...
(a) a byte is defined as 8 bits.
(b) a kilobyte is 1000 bytes. (actually 1024)
(b) a megabyte is 1000 KB. (actually 1024)
So the sizing of memory values is external to the bit-width of
operations and operands on a CPU.
Additionally because x86 processors - even the x64 variants are still
"CISC" style chips, they have variable bit length instructions. An ADD
instruction might be 4 bits wide (and still work on 64 bit operands),
whereas an SSE instruction might be 24 or 32 bits wide. Hence x86 CISC
chips have to do more work to "decode" instructions as they come to the
CPU... RISC was viewed as an improvement as all operations, and
operands were fixed width. So a 32 bit RISC chip all instructions were
32 bits wide, and worked on 32 bit wide operands. Hence binary sizes
for RISC chips were typically larger than the equivalent CISC binary -
which might be the source of misapprehension concerning memory usage
when increasing bit width of a CPU.
BJ Freeman wrote:
the is slightly off topic:
when you increase the bits of a processor, the available ram is decreased.
so 2 gig on a 32 bit is only usable 1 gig on 64 bit.
so unless the code in javaVM at the machine level is taking advantage of
the 64 bit instruction set, you are not gaining anything.
What usually happens it the complied runtime is still using the 32 bit
instruction set, on a 64 bit cpu. until they go in and optimize the
machine code generated.
Walter Vaughan sent the following on 3/29/2007 8:00 AM:
Is anyone working with ofBiz in 64 bit mode? I'm looking at
configuring/leasing a server (dual quad core box), and to get the javaVM
to use more than 2Gig of memory from what I've read, I need to run a 64
bit JavaVM.
I know this probably is way overkill, but the cost is reasonable right
now for these servers, and we've got time to 'speriment, and if we have
to,we can still run this stuff in 32bit mode.
--
Walter
