(Forgot all about this thread, coming back to it now... )
But I don't understand how *that* is relevant. If the data being fetched is 32 bit words, that's going to be 4 or 8 words of data. If it's 64 bit words, it's going to be 2 or 4 words of data.
Note that you're still within the size of data that is fetched with a single memory access by the caching mechanism. Say you have a single 32bit piece of data - a class var or (in C) static variable. If your word size is 32bit, that's a single fetch. If your word size is 64bit, it is still a single fetch. If you were to fetch no other data around that one variable, there would be no performance penalty to pay regardless of whether you are using a 32 or 64bit CPU because that actual amount of data fetched is greater than what you requested. (you request 32bits, but the cache strategy always fetches blocks of 256bits of data).
The one assumption made in my argument is that you're accessing just a single variable. Of course, if you're doing processing on a large array of data, then yes, we can assume a better response from the smaller data size if we're interating through a large array.
An additional factor to weigh in here is the nature of your C compiler. That int may be compiled as 32bit or 64bit depending on the platform. Unlike Java, that states an int shall always be 32bits, C does not have this restriction. The int may be 16,32 or 64 bits depending on the compiler and platform.
If I were being more cautious, I would merely have said that whilst bus throughput continued to be a signficant bottleneck that 64 bit hardware has downsides.
If this were a C or C++ programming forum, I might be inclined to agree with you, but would focus more on the caching side of the argument. Still for them, bus issues are less of an issue than just trying to keep as much stuff cached as possible so that the bus doesn't come into play. However, since we're in the Java world, we don't really even have that level of control. The VM is inclined to do all sorts of tricky stuff that we just have no control over, particularly with regards to caching strategies.
When I said "demand a mode" I meant in a vague, generic sense. I didn't mean I wanted some kind of API for pro-actively demanding it, I meant I just wanted a complete system that had that capability, which the JVM could then take advantage of when it realised that I wasn't using any 64 bit variables.
Remember that due to the strict data size requirements of the Java language that unless you are using longs or doubles, this will always be the case. Also, take note of my first reply - running the wrong size data on the CPU can cause very significant performance problems. Forcing the use of 32bit data on a 64bit machine probably will cause that code to run slower than if it had just used the native word size. That's the root of my points - just because the machine is 64bit, doesn't mean that 32bits is going to be more efficient and thus there should be some way of telling the JVM to "only deal with 32bit data". Given past history and the benchmarks that are coming out now for the AMD64/Ia-64 machines, it's almost guaranteed to perform worse than if you'd just stuck with the machine's native word size and not tried to force "optimised" code execution onto it.