-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony,
On 3/1/2011 4:19 PM, Tony Anecito wrote: > I guess you have not read my last email yet. I think of it as putting two > 32-bit pieces of info on a 64-bit data bus whereas for two 64-bit pieces of > information it takes two fetches or twice as long on the same hardware. Are you saying that a 32-bit JVM running on a 64-bit machine somehow utilizes the 64-bit bus? Malarkey. Perhaps the CPU as part of its instruction re-ordering can do this, but I seriously doubt that a 32-bit process on a 64-bit CPU gains a performance boost over that same 32-bit process running on a 32-bit CPU (which is what the above would imply). > As for compressing the pointers all I read is it improves response time I can't believe that for a second. It actually slows things down. The only reason to compress pointers is so that your heap size doesn't roughly double when switching to 64-bit. The problem is that while the transition from 32-bit to 64-bit architecture now allows many orders of magnitude more memory to be accessed by each process (this is especially important for Java heaps), the amount of memory installed in servers has not really changed. 5 years ago, it wasn't uncommon for a 32-bit server to have 32GiB of memory. These days, a similar 64-bit server might still only have 32GiB of memory. > so that > maybe running on 64-bit java the program is only 1% slower. I am assuming the > pointers are compressed after the first pass or even before the byte code is > run. The pointers are compressed as the objects (really the references to them) are created. The problem is that they must be uncompressed for every dereference. It has nothing to do with the bytecode. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1tbJUACgkQ9CaO5/Lv0PBZ3ACgrVFqcPNcIe+P3U1HW3QzRXpS L3oAnj82GTkXoQcOwxYskRLXWwsrFTcn =w2cy -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
