64bit - 32bit 的一些解释

最后一天，整理电脑发现上次查找64-32位JDK的一些问题时的一份资料。还通过金山词霸翻译了的。哈哈，有错就怪金山词霸咯。。

 

为什么排版这么烂

---------------------------

 

 

原文：http://asserttrue.blogspot.com/2008/11/why-64-bit-java-is-slow.html 

 

In an interesting post at the WebSphere Community Blog, Andrew Spyker explains why it is that when you switch from 32-bit Java to a 64-bit runtime environment, you typically see speed go down 15 percent and memory consumption go up by around 50 percent. The latter is explained by the fact that addresses are simply bigger in 64-bit-land, and complex data structures use a lot of 64-bit values even if they only need 32-bit values. The reason performance drops is because although address width has gotten bigger, processor memory caches have not got bigger in terms of overall Kbytes available. Thus, you are bound to see things drop out of L1 and L2 cache more often. Hence cache misses go up and speed goes down.

在WebSphere的社区有一篇有趣的博文，andrew解释了为什么从32位java环境切换到64位时速度会下降15个百分比，并且内存消耗会提高50%. 后者使用复杂的64位大地址，并且大量使用64位的数据结构，即使他们仅仅需要的是32位的值。尽管带宽更大了, 但这就是性能下降的原因， 总的来说，处理内存缓存时并不能获得更多有效的字节数（因为好多32bit是废的，按照前面的说法）. 因此，你肯定会经常遇到数据被移除L1,L2缓存。因此，缓存的丢失率提高，速度就有所下降啦。

 

 

Why, then, would anyone invest in 64-bit machines if the 64-bit JVM is going to give you an immediate performance hit? The answer is simple. The main reason you go with 64-bit architecture is to address a larger memory space (and flow more bytes through the data bus). In other word, if you're running heap-intensive apps, you have a lot to gain by going 64-bit. If you have an app that needs more than around 1.5 GB of RAM, you have no choice.

既然如此，64位的JVM不能立即给你提升性能，为什么有人愿意去搞它呢？这个答案so easy. 如果使用64位，那么它将带来更多的地址空间，可以使用更多的内存（并且总线的吞吐量更大）。 换句话说，如果你运行的程序需要用到更多的内存，使用64位机器（JVM），那么你的内存可使用量将剧增。 如果你的程序不需要大于1.5GB的内存，那么可以不选择使用它。

 

 

Why 1.5GB? It might actually be less than that. On a 4GB Win machine, the OS hogs 2GB of RAM and will only let applications have 2GB. The JVM, of course, needs its own RAM. And then there's the heap space within the JVM; that's what your app uses. It turns out that the JVM heap has to be contiguous (for reasons related to garbage collection). The largest piece of contiguous heap you can get, after the JVM loads (and taking into account all the garbage that has to run in the background in order to make Windows work), is between 1.2GB and 1.8 GB (roughly) depending on the circumstances.

为什么是1.5GB？ 实际上有可能还比他更小。 在一个4GB内存windows上的机器， 操作系统就占据了2GB的内存，剩下的2GB将分配给应用程序. JVM也是普通的应用程序，因此它也是需要内存的。 这些内存实际上就是JVM里面的堆空间了. 你的应用程序使用的内存就是这部分. 当虚拟机加载后，你就可以获取这些堆空间(还需要考虑到在后台工作的垃圾回收), 它在1.2GB到1.8GB（毛算的值）之间，具体值依赖于系统的实际环境。

 

 

To get more heap than that means either moving to a 64-bit JVM or using Terracotta. The latter (if you haven't heard of it) is a shared-memory JVM clustering technology that essentially gives you unlimited heap space. Or should I say, heap space is limited only by the amount of disk space. Terracotta pages out to disk as necessary. A good explanation of how that works is given here.

要使用更多的堆空间，只有转移到64位平台的JVM，或者使用Terracotta(一个JVM级别的分布式的缓存？). 后者(如果你没有听说Terracotta)是一个JVM集群式内存共享技术， 理论上这可以给你带来无限的堆空间.  或者，我可以这样来解释，堆空间相对于磁盘空间是有限的, 但是Terracotta在必要时可以输出到磁盘空间. 这就很好的解释了Terracotta是如何工作的.

 

 

But getting back to the 64-bit-memory consumption issue: This issue (of RAM requirements for ordinary Java apps increasing dramatically when you run them on a 64-bit machine) is a huge problem, potentially, for hosting services that run many instances of Java apps for SaaS customers, because it means your scale-out costs rise much faster than they should. But it turns out there are things you can do. IBM, in its JVM, uses a clever pointer-compression scheme to (in essence) make good use of unused high-order bits in a 64-bit machine. The result? Performance is within 5 percent of 32-bit and RAM growth is only 3 percent. Graphs here.

回到64位内存消耗的问题：这个问题（为了获取更多的内存需求，运行在64bit的java程序与日俱增）是一个头痛的问题, 一台主机服务他们可以为多位SaaS客户运行了许多java程序，因为这样做可以节约很多成本, 让你可以做更多的事情。 IBM的虚拟机使用智能的指针编译规则可以在64位机器中创建高效字节位。 结果？ 性能近和32bit相差5%， 内存差距仅为3%。 从这里看图

 

 

Oracle has a similar trick for BEA's JRockit JVM, and Sun is just now testing a new feature called Compressed oops (ordinary object pointers). The latter is supposedly included in a special JDK 6 "performance release" (survey required). You have to use special command-line options to get the new features to work, however.

Oracle为BEA的JRockit JVM也提供了类似的技术， 而sun现在仅有一个还处于测试阶段的特性，它叫做Compressed oops(ordinary object pointers)，预计它将作为JDK6 "performance release" 这个特殊的版本发放（投票？）， 你可以在你的工作中使用特殊的命令行参数来启用这个新特新。

 

 

 

Anyway, now you know why 64-bit Java can be slow and piggish. Everything's fatter in 64-bit-land.

无论如何，你现在知道了为什么64位java慢，并且内存占用大了。 在64位环境中，任何东西都比原来大。。。

 

 

For information about large-memory support in Windows, see this article at support.microsoft.com. Also consult this post at sinewalker.

关于在win中，大内存的支持，看这篇文章， 它在support.microsoft.com. 另外，也可以在sinewalker阅读它.