execution engine：
- 运行时栈current stack frame主要保存了 local variable table， operand stack， dynamic linking， return address and some other additional info。
- 方法调用（确定调用哪个方法的过程）：这类加载阶段就能够确定调用版本的符号应用，直接转化为方法的直接引用（方法在内存中的入口地址），这其中有四类方法：静态方法、私有方法、实例构造器<init> 和 父类方法，这类方法也统称为非虚方法，其他的方法都称为虚方法（除去final修饰的方法）。
- 静态分派（Static dispatch，典型应用method overload resolution）：静态分派是依赖静态类型来定位方法执行版本的分派动作，它发生 在编译阶段，因此确定分派的动作不是由虚拟机执行的。在确定方法的重载版本时，很多时候匹配的方法并不唯一，往往只能确定一个“更合适”的版本（因为字面量没有显示的静态类型）。
- 动态分派（典型应用：override）：多态，即 Java虚拟机根据对象引用的实际类型确定方法版本的过程，实际对应invokevirtual指令的多态查找过程。具体步骤：1）找到操作数栈顶元素所指向对象的实际类型，记作C。2）如果找到与常量中的描述符和简单名称都相符的方法，则进行访问权限的校验，通过则返回直接引用；否则，返回java.lang.IllealAccessError异常。3）否则，按照继承关系从下往上依次对C的父类进行过程2。4）如果还没找到，抛出java.lang.AbstractMethodError。
- 目前，Java语言是一门静态多分派、动态单分派的语言。
早期（编译期）优化：com.sun.tools.javac.main.JavaCompiler类是编译的入口，下面是该类的主体代码。
try {
738 initProcessAnnotations(processors);//初始化插入式注解处理器
739
740 // These method calls must be chained to avoid memory leaks
741 delegateCompiler = processAnnotations(//执行注解处理
enterTrees( stopIfError(//输入到符号表
parseFiles(sourceFileObjects))),//词法分析和语法分析
742 classnames);
743
744 delegateCompiler.compile2();//分析和字节码生成
745 delegateCompiler.close();
746 elapsed_msec = delegateCompiler.elapsed_msec;
747 }
方法compiler2：
760 private void compile2() {
761 try {
762 switch (compilePolicy) {
763 case ATTR_ONLY:
764 attribute(todo);
765 break;
766
767 case CHECK_ONLY:
768 flow(attribute(todo));
769 break;
770
771 case SIMPLE:
772 generate(//生成字节码
desugar(//解语法糖
flow(//数据流分析
attribute(//标注
todo))));
773 break;
语法糖（Syntactic sugar）是一种编程语言中添加的某种语法，它对语言的功能并没有影响，但是更方便程序员的使用，并增加程序的可读性，减少出错的机会。Java中与之相关的有：泛型、自动装箱拆箱、遍历循环和条件编译。
我有看了一遍Dynamic Code Evolution for Java 这篇文章。 下面写一下阅读总结：
- introduction部分介绍了DSU的四个方面的应用：Debugging（本文主要就是这个目的），Sever Application（Jvolve 的应用目标），Dynamic language（改进的ＶＭ课可以更容易的支持动态语言），Dynamic AOP。这篇文章的contribution：修改了HotSpot VM使之能够完成DCE；
在不增加新模块，不损失ＶＭ性能的前提下，允许 arbitrary changes ；
一个更新可以在任意Java程序可以被suspend的地方执行；
可以把修改过的HotSpot VM与使用JDWP协议的IDE集成。 - levels of code evolution： 方法体的修改； 增删方法； 增删域； 增删父类 （越往后， 实现的复杂度越高）
- 实现时，使用JDWP中的一个特殊命令来启动更新的过程。结合HotSpot VM的内部实现，主要修改了garbage collector， system dictionary and class metadata（这些修改不会影响到Java program的正常执行）。 具体过程是： 寻找受影响的类，按照继承的拓扑结构排序； 建立 side universe（在垃圾回收中修改受影响的object时，用于中转）；然后就是实际的修改pointer，update instance； state invalidation。
- 对于binary incompatible change（Fields， methods的删除，父类的修改引起的old code的失效），DCE 要么会抛出异常， 要么 直接导致ＶＭ突然终止。 作者给出理由是： 面向debug的，这两种情况都可以接受，而且找到了错误的来源（比什么现象都没有要好）。
- 有效性测试，对正常程序影响的测试，围观基准程序测试（比较效率）
- Related work： 在6.4java中提到了Jvolve，由于应用场景的不同，Jvolve 不允许binary incompatible change的存在，因此Jvolve 对更新点的选择更为严苛，对更新的类型也减少了 （class hierarchy不允许改变）。