I may have stated it in a way that gave a misconception. this is more of sales against technical. it would be assumed that when a computer says it has 2 gigs of memory for a 64 bit process that would be for the 64 bit addressing space. however marketing wants to make it look bigger so there reference to 2 gigs is 32 bit wide memory modules. so 2 gigs of 32 bit wide memory modules, equals 1 gigbyte of 64 bit addressing.
Porter Woodward sent the following on 3/29/2007 12:00 PM: > 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 >>> >>> >>> >>> >> >> > > >
