谁有那个深入分析基于寄存器和基于栈的虚拟机的文章啊？

Question

找了好久啊没找到， 郁闷啊郁闷

Answer 1

楼主，你找到了发我一份，
[email protected]游戏脚本编程一书里面讲的还是很详细的，要想弄这个，很细节的东西，买本书吧。

Answer 2

用JVM知识解释几个简单的技术问题         例如，对象可以直接访问实例数据和局部变量，这是因为如果将实例数据单独放在对象池中，此时，一个对象引用，也就是一个指向句柄池的指针，可以通过“指向对象池的指针”来访问实例数据，如果实例数据和“指向类数据的指针”放在一起，此时，一个对象引用，也就是一个指向堆的指针，可以直接通过这个“指向堆的指针”来访问实例数据，堆用来存放程序在运行时创建的所有类实例或数组，在第一种设计中，句柄池和对象池都属于堆，因此可以看出，这两种方式在本质上是一样的，只是一种方式是将堆分开进行计算，而另一种方式没有分开，所以，无论是哪种设计，对象都可以直接访问实例数据和局部变量，但是，对于类数据和方法数据，无论是哪种设计，它们都存放于方法区中，只有“指向类数据的指针”才能访问方法区，所以，无论是哪种设计，对象都必须通过一个间接的方式去访问类数据和方法数据。 
        再比如，一个类实例要转换成另一个类实例，它不能是另一个类实例的父类，这是因为在Java虚拟机设计中，类的加载顺序是按照从本类、父类直到启动类的顺序依次向上加载上去的，如果一个类实例在转换成另一个类实例时它是另一个类实例的父类，那么，这种加载原则是必会减少所加载的类的个数，影响程序的访问权限，这显然是与程序设计的原则相违背的。 
        还有，假如当一个用户去点击一个提交按钮后，将产生一个线程，每一个用户去点击这个提交按钮就相当于这个线程多次去调用同一个Java方法，这就相当于每次在Java栈中压入一个新帧，而帧是用来存储参数、局部变量和中间运算结果的，因此，每次方法调用都不会相同，得到的结果，如果保存在对象中将放在堆上，如果保存在类变量中将放在方法区上，此时，无论是句柄池和对象池都属于堆还是实例数据和“指向类数据的指针”放在一起，都是一个对象指针去访问一个堆，再通过被访问的堆中指向类数据的指针去访问类数据，因此，有可能就会出现多线程下访问同一个堆的同步问题，一般采取对象锁机制去解决这样的问题，对象锁就相当于给同一个房子里的十个人只一把钥匙，而任意一个时刻只有一个人才能拥有这把钥匙进入房子，而其他人只能等待直到有钥匙的这个人将钥匙交给了下一人为止，对象锁正是通过这种将时间进行线性控制的方法来解决“多线程下访问同一个堆的同步问题”的，之所以要采用这种排队方式那是因为每当线程调用一个Java方法时虚拟机都会在该线程的Java栈中压入一个新帧，而Java栈只支持出栈和压栈操作。

Answer 3

哈哈哈我找到了google "Register-based VM vs Stack-based VM "就可以看到很多了

Answer 4

http://www.usenix.org/events/vee05/full_papers/p153-yunhe.pdf同志们看这个PDF，里面详细比较了，哈哈哈，我终于找到了

Answer 5

http://morganchengmo.spaces.live.com/blog/cns!9950CE918939932E!1234.entry?wa=wsignin1.0
Stack-based vs Register-based
要真正用好一项技术，就一定要理解技术表面之下的东西。使用C#，不能光知道怎么写基本语句，记住常用API就完事了，要知道这背后的东西，能够看懂编译之后产生的MSIL是必要的。 今天学习了一下MSIL，还是有点惊诧，本以为和x86的汇编代码差不多，但是发现自己一开始什么也看不懂，而且工作方式和x86也很不一样。x86汇编代码中，是对一个一个寄存器进行操作，而IL里面没有寄存器这个概念，所有被操作的东西都先push到栈上，然后调用一个指令，然后再pop取得结果。 x86的这种方式叫register-based，MSIL这种方式叫stack-based。 理论上，stack-based的方式比起register-based的方式有很多优点。 一般指令中每个元素都至少占一个byte，对于register-based，一个求和指令，只能写成类似这样的     ADD R1, R2, R3
    ADD R1, R2第一种方式，ADD是opcode，R1和R2是输入，加的结果放在R3里面，如果和第二种方式一样，R1和R2只和就放在一个缺省的寄存器或者R1和R2之中一个，总之至少需要3个byte来描述一条加动作的指令。而对于stack-based，被加的数在栈上，输出也要放在栈上，一个byte的指令就够了，当然把输入放在栈上还需要别的指令，但是对于一串连续的指令流，往往前一条指令的输出（放在栈上），就是后一条指令的输入，所以整体而言，stack-based的代码会比register-based小。 同样的道理，stack-based中调用函数也方便得多，不需要像register-based一样把register上得东西先push到栈上(当然根据convention，有的参数和返回值也可以直接放在register里面)。 运行环境(进程或线程)的切换，stack-based也方便得多，和当前运行环境状态相关的变量都在栈上，只需要让指令到另外一个栈上去跑就好了，等切换回来一切和从前一样。对于register-based，不得不在切换之前把register一一存下来，切换回来再一一恢复，如果reigster比较多，开销就比较大。 既然stack-based这么牛，那为什么我们常见的处理器都不是stack-based，而傻傻的用register-based呢？这是因为regiser-based纵有千般不是，它的性能高，它适应市场。我们知道同样的容量，硬盘比内存便宜，内存比缓存便宜，缓存比寄存器便宜，构成了金字塔形状的层层cache关系，register最贵但是也访问最快。如果实现一个stacked-based的CPU，那么很大一个问题就是不可能造一个很大的放在CPU中的stack，所以时不时还是需要停下来从内存中取数据到on-chip stack，这样反而把性能降低了。 对于解释性语言，是在VM上跑，不是直接在硬件CPU上跑，所以可以不考虑这些问题，虽然有如parrot这样register-based的，但是绝大多数都是stack-based，其中包括MSIL

Answer 6

有空的话可以去买一本深入JAVA虚拟机看看　不过那本书看得挺吃力的