-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony,
On 3/1/2011 3:24 PM, Tony Anecito wrote: > Also, I have not programmed in assembly language or in hexadecimal for some > time but I would hope that for a 32-bit java process running on a 64-bit > processor I would fetch a 32-bit pointer and maybe a 32-bit long on a 64-bit > data bus. Remember we are talking about pointers in code coming into the > processor via the data bus. The bus on a 64-bit architecture has better be at least 64-bits wide, otherwise nothing works right. They used to run 64-bit OSs on 32-bit hardware and everything took twice as long because the bus was only 32-bit and so every piece of (64-bit) data took double the time to transmit. Booting 64-bit WinNT would take a looong time. I don't understand why communicating a 64-bit value over a 64-bit bus would take longer than communicating a 32-bit value over a 64-bit bus: the clock speed of the bus is the same... the only difference between the two scenarios is that the user doesn't care about the upper 32-bits of data. The only thing that makes sense to me intuitively at this point (I'm still reading) is that using compressed object pointers slows things down. > Interesting enough for AIX and Linux a long is 64bit for 64-bit java versus > 32-bit for 64-bit windows. So it looks like for Linux it would be slower than > windows. > See: > http://public.dhe.ibm.com/software/dw/jdk/64bitporting/64BitJavaPortingGuide.pdf That's interesting, though it doesn't specify what compiler is being used. The only thing that makes a "long" value 32-bit or 64-bit is the compiler compiling the code where the word "long" is present. Java fixes the size of all native data types, so a Java "long" is always 64-bits regardless of the architecture. ISO C declares that "long" is "at least" 32-bit, short is "at least" 16-bit, and plain-old "int" is somewhere in between whatever short and long turn out to be. That document seems to imply that the OS decides what the type widths are, and that only matters when interfacing with OS calls: if you call brk() and it expects a 64-bit value, if you provide a 32-bit one, bad things will happen. > Bottom line on how much worse things get is based upon how many pointers and > longs are used for 64-bit java that are used. I still don't get why moving 64-bit values around is slower than moving 32-bit values around: the bus is 64-bits no matter what mode you're in. I *do* get that compressed pointers slow things down. I *do* get that the heap will grow somewhere approaching twice the size as in a 32-bit JVM. I also get that some processors (like Itanium) have an x84 processor core on the die, so that processor can avoid (uselessly) performing 64-bit operations on 32-bit data, but getting the data from point A to point B shouldn't matter. Also, performing 64-bit operations on 32-bit data should take just as long as performing 64-bit operations on 64-bit data: the ALU goes as fast as it's designed to go. I suppose of the CPU knew it was in a 32-bit mode, it could adjust the number of clock ticks it had to wait around for 32-bit data to go through an adder, but that seems overly complicated for a straightforward CPU task. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tXrsACgkQ9CaO5/Lv0PBJfgCfXoAqt/K8TzqGk5AYO2+g4n7J OsMAoIbJ1nRUFVDilUDdkQTTOrRoMNWb =d3UM -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
