tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [OT] IIS7/isapi/tomcat performance
Date Tue, 01 Mar 2011 21:01:48 GMT
Hash: SHA1


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: 

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
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message