JVM 64位pointer compress, Erlang呢？

前端时间看到JVM的 64 pointer compress技术，蛮多感慨的。具体的可以 google
64位 pointer compress 来了解更多。

好不容易从32位系统中逃脱，解决了4G内存的问题，而且64位的cpu更多的寄存器， 可以带来更好的性能。但是怎么又碰到问题了。64位的系统，64位的指针，意味着更多的数据访问， cpu速度是提高了，但是内存的带宽和访问速度没有大的提高。 而且内存的访问速度和cpu的cycle差几个数量级别，所以对于普通的网络程序来讲，大部分是处理信息的变形，也就是说是把内存里面的数据从一个形式变成另外一个形式。 cpu性能的提高对这种程序来讲 影响不是很大。倒是因为数据的量加大了1倍， 导致整体的性能降低了百分几十。 实际的硬件系统也没有那么多内存，一般都是16G以下，所以才有人去想在64位系统下，用36位的指针，减少内存的访问。

erlang的系统基本上是个网络程序，所以这个问题就非常突出。 目前没看到otp vm的这方面的打算， 我还是乖乖的用我的32位系统。

要压缩指针，一个VM的堆必然要小于4G。
我觉得可以通过Vmware之类让多份x86-32的OS的跑在x64平台上，以便方便的实现一机多OS，以及“指针压缩”了。

ms 指针压缩是为了减少内存占用，而不是提高速度。比如一个链表，previous 和 next，都是一个指针，所有会占用2*64bit，即16byte的内存，所以采用某种形式来减少内存占用，通常的idea就是利用offset，某个基地址的偏移量，比如32bit偏移量，每个链表节点，只消耗8byte内存，但偏移量是以消耗CPU计算时间和地址空间长度来换取内存减少，真要访问内存的某个数据，指针还是会被还原回最初的状态。


对于网路应用，也有重要的硬件，比如TOE网卡

R14A halfword已经支持了 在64位机器上 eterm的指针还是用32位!!!

hotspot里compressed oop可以支持到32G的heap，因为在64位系统里一般指针都有8字节对齐的要求，这样最后3位都是0，32位压缩指针可以表示的范围是4G*8=32G

实际上compressedOop是提高性能的，打开这个选项benchmark大概能有5%的提高，主要是cache miss的降低和gc的压力减少

对的 指针小了 访问的内存也就少了 速度就快了

我在我的应用上， 测试的时候， 发现大约提高了20％。。。。很神奇。。。