1. 技术文章
  2. 晚期（运行期）优化

晚期（运行期）优化

由 对着背影说爱祢 提交于 2020-02-07 17:40:34

一、概述

  1. 部分商用虚拟机中，Java程序最初通过解释器进行解释执行，当虚拟机发现 某个方法或代码块的运行特别频繁 时，就会把这些代码认定为"热点代码"。

  2. 为了提高热点代码的执行效率，在运行时，虚拟机将会 把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为 即时编译器


二、HotSpot虚拟机内的即时编译器

2.1 解释器与编译器

  事实上，现在许多主流的商用虚拟机，如HotSpot、J9等，都同时包含有解释器与编译器。解释器与编译器两者各有优势：

  • 当程序需要快速启动和执行的时候，解释器可以首先发挥作用，省去编译的时间，立即执行

  • 在程序运行后，随着时间推移编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获得更高的执行效率。

  • 当程序运行环境中内存限制较大时，可以使用解释执行节约内存，反之可以使用编译执行提高效率

同时，解释器还可以作为编译器激进优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化的假设不成立，如加载了新类后类型继承结构出现变化、出现罕见陷阱时可以通过逆优化退回到解释状态继续执行（部分没有解释器的虚拟机中也会采用不进行激进优化的C1编译器担任“逃生门”的角色）。因此，解释器与编译器经常配合工作，如下图所示：
在这里插入图片描述

2.1.1 Client Compiler 与 Server Compiler

  HotSpot虚拟机中内置了两个编译器，分别称为Client Compiler和Server Compiler或者称为 C1编译器和 C2编译器（也叫Opto编译器）。目前主流的HotSopt虚拟机（Sun系列JDK1.7及之前版本的虚拟机）中，默认采用解释器与其中一个编译器直接配合的方法工作，程序使用哪个编译器，取决于虚拟机运行的模式，HotSpot虚拟机会根据自身版本与宿主机器的硬件性能自动选择运行模式，用户也可以使用“-client”或“-server”参数去强制指定虚拟机运行在Client模式还是Server模式。

  • “混合模式”：解释器与编译器搭配使用的方式

  • 使用参数“-Xint”强制虚拟机运行于“解释模式”
    这时编译器完全不介入工作，全部代码都使用解释方式执行。

  • 使用“-Xcomp”强制虚拟机运行于“编译模式”
    这时将优先采用编译方式执行程序，但是解释器仍然要在编译无法进行的情况下介入执行过程。

可以通过虚拟机的“-version”命令输出结果显示出这三种模式：

C:\>java -version
java version "1.8.0_221"
Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)

C:\>java -Xint -version
java version "1.8.0_221"
Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, interpreted mode)

C:\>java -Xcomp -version
java version "1.8.0_221"
Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, compiled mode)

2.1.2 分层编译

  为了在程序启动响应速度与运行效率之间达到最佳平衡，HotSpot虚拟机还会逐渐启动分层编译的策略，分层编译的概念在JDK1.6中出现，后来一直处于改进阶段，最终在JDK1.7的Server模式虚拟机中作为umoren编译策略被开启。分层编译根据编译器编译、优化的规模与耗时，划分出不同的编译层次，其中包括：

  • 第0层，程序解释执行，解释器不开启性能监控功能（Profiling），可触发第1层编译。
  • 第1层，也成为C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要时将加入性能监控的逻辑。
  • 第2层（或2层以上）：也成为C2编译，也是将字节码编译为本地代码，但是会启动一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化。

  实施分层编译后，Client Compiler和Server Compiler将会同时工作，许多代码都可能会被多次编译，用Client Compiler获取更高的编译速度，用Server Compiler来获取更好的编译质量，在解释执行的时候也无须再承担收集性能监控信息的任务。

2.2 编译对象与触发条件

2.2.1 编译对象

在运行过程中会被即时编译器编译的“热点代码”有两类：

  • 被多次调用的方法；
  • 被多次执行的循环体。

  对于第一种情况，由于是由方法调用触发的编译，因此编译器会以整个方法作为编译对象，这种编译也是虚拟机中标准的 JIT编译方式。而对第二种情况，尽管编译动作是由循环体所触发的，但编译器依然会以整个方法作为编译对象，这种编译方式因为编译发生在方法执行过程之中，因此形象地被称为 栈上替换，简称为 OSR编译，即方法栈帧还在栈上，方法就被替换了。

2.2.2 触发条件

  在这里提一个问题，被多次调用，在这里的多次具体是多少次？并且虚拟机如何统计一个方法或一段代码被执行过多少次？

  判断一段代码是不是为热点代码，是不是需要触发即时编译，这样的行为称为热点探测，但进行热点探测也是不一定要知道方法具体被调用了多少次，目前主要的热点探测判定方法有两种：

  • 基于采样的热点探测
    虚拟机会周期性地检查各种线程的栈顶，如果发现某个或者某些方法经常出现在栈顶，那这个方法就是“热点方法”。
    优点：实现简单、高效，还可以很容易地获取方法调用方法。
    缺点：很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。

  • 基于计数器的热点探测
    虚拟机会为每个方法（甚至是代码块）建立计数计数器，统计方法的执行次数，如果执行次数超过一定的阙值就认为它是热点方法。
    优点：统计结构相对来说更加精确与严谨。
    缺点：实现起来麻烦，需要为每个方法及建立并维护计数器，而且不能直接获取到方法的调用关系。

在HotSpot中使用的是第二种方法——基于计数器的热点探测法，因此它为每个方法准备了两类计数器：

  • 方法调用计数器
  • 回边计数器

这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。

方法调用计数器：统计方法调用的次数

默认阈值

  • Client模式：1500次
  • server模式：10000次

可通过虚拟机参数 -XX：CompileThreshold 来人为设定。

  当一个方法调用时，会先检查该方法是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行，如果不存在已被编译过的版本，则将此方法的调用计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过方法调用计数器的阈值，如果已超过阈值，那么将会向即时编译器提交一个该方法的代码编译请求。
  如果不作任何设置，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方法执行字节码，直到提交的请求被编译器编译完成。当编译工作完成之后，这个方法的调用入口地址就会被系统自动改写成新的，下一次调用该方法时就会使用已编译的版本。
在这里插入图片描述

如果不做任何设置，方法调用计数器统计的是方法在一段时间内被调用的次数，当超过一定的时间限度，如果方法的调用次数扔不足以让它提交给即时编译器编译，那这个方法的调用计数器就会被减少一半，这个过程称为方法调用计数器热度的衰减(Counter Decay)，而这段时间就称为此方法统计的半衰周期(Counter Half Life Time)。进行热度衰减的动作是在虚拟机进行垃圾收集时顺便进行的，可以使用虚拟机参数-XX：-UseCounterDecay来关闭热度衰减，让方法计数器统计方法调用的绝对次数，这样，只要系统运行时间足够长，绝对大部分方法都会被编译成本地代码。

回边计数器：统计一个方法中循环体代码执行的次数

  在字节码中中遇到控制流向后跳转的指令称为“回边”。建立回边计数器的目的是为了触发OSR编译。关于回边计数器的阈值，HotSpot虚拟机也提供了-XX: BackEdgeThreshold设置回边计数器的阈值，但当前虚拟机实际上并未使用此参数，可以通过设置另外一个参数-XX: OnStackReplacePercentage来间接调整回边计数器的阈值，其计算公式如下：

  • 在Client模式，回边计数器阈值公式为：
    方法调用计数器阈值（CompileThreshold）×OSR比率(OnStackReplacePercentage)/100。

其中OnStackReplacePercentage默认值为933，如果都取默认值，那Client模式虚拟机的回边计数器的阈值为13995。

  • 在server模式下，回边计数器阈值公式为：
    方法调用计数器阈值（CompileThreshold）×(OSR比率-解释器监控比率（InterpreterProfilePercentage）)/100。

其中OnStackReplacePercentage默认值为140，InterpreterProfilePercentage默认值为33，如果都取默认值，那Server模式虚拟机的回边计数器的阈值为10700。

  当解释器遇到一条回边指令时，会先查找将要执行的代码片段是否已经有编译好的版本，如果有，他将会优先执行已编译的代码，否则就把回边计数器值加1，然后判断方法调用计数器与回边计数器值之和是否超过回边计数器的阈值。当超过阈值时，会提交一个OSR编译请求，并把回边计数器的值降低一些，以便继续在解释器中执行循环，等待编译器输出编译结果。
在这里插入图片描述

回边计数器没有热度衰减的过程，因此这个计数器统计的就是该方法循环执行的绝对次数。当计数器溢出时，它会把方法计数器的值也调整到溢出状态，这样下次再进入该方法就会执行标准编译过程。

2.3 编译过程

  在默认设置下，无论是方法调用产生即使编译请求，还是OSR编译请求，虚拟机在代码编译器还未完成之前，都仍然将按照解释方式继续执行，而编译动作则在后台的编译线程中进行。 用户可以通过参数-XX: -BackgroundCompilation来禁止后台编译，禁止后台编译后，一旦达到JIT的编译条件，执行线程向虚拟机提交编译请求后将会一直等待，直到编译过程完成后再开始执行编译器输出的本地代码。

在后台执行编译的过程中，编译器做了什么？Server Compiler和Client Compiler两个编译器的编译过程是不同的。

2.3.1 Client Compiler 编译过程

  简单快速的三段式编译器，主要的关注点在于局部性的优化，而放弃了许多耗时较长的全局优化手段。

  • 第一个阶段：一个平台独立的前端将字节码构造成一种高级中间代码表示（HIR）

HIR使用 静态单分配 的形式来表示代码值，这可以使得一些在HIR的构造过程之中和之后进行的优化动作更容易实现。在此之前，编译器会在字节码上完成一部分基础优化，如方法内联、常量传播等优化将会在字节码被构造成HIR之前完成。

  • 第二个阶段：一个平台相关的后端从HIR中产生低级中间代码表示（LIR）

而在此之前，在HIR上完成另外一些优化， 如空值检查消除、范围检查消除等，以便让HIR达到更高效的代码表示形式。

  • 最后阶段：在平台相关的后端使用线性扫描算法在LIR上分配寄存器，并在LIR上做窥孔优化，然后产生机器代码。

在这里插入图片描述

2.3.2 Server Compiler 编译过程

  对于Server Compiler则是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译期，也是一个充分优化过的高级编译器，它会执行所有经典的优化动作。

如无用代码消除，循环展开，循环表达式外提，消除公共子表达式，常量椽笔，基本块重排序等，还会实施一些与Java语言特性密切相关的优化技术，如范围检查，空值检查消除等。还可能根据解释器或Client Compiler提供的性能监控信息，进行一些不稳定的激进优化，如守护内联，分支频率预测等。

  Server Compiler的寄存器分配器是一个全局图着色分配器，它可以充分利用某些处理器架构（如RISC）上的大寄存器集合。所以它也是比较缓慢的，但它的编译速度依然远远超过传统的静态优化编译器，而且它相对于Client Compiler 编译输出的代码质量有所提高，可以减少本地代码的执行时间，从而抵消了额外的编译时间开销，所以很多非服务端的应用选择使用server模式的虚拟机运行。

2.4 查看及分析即时编译结果

public class JITTest {
    public static final int NUM = 15000;

    public static int doubleValue(int i){
        for(int j = 0; j < 100000; j++);
        return i*2;
    }

    public static long calcSum(){
        long sum = 0;
        for(int i = 1; i <= 100; i++){
            sum += doubleValue(i);
        }
        return sum;
    }

    public static void main(String[] args) {
        for (int i = 0; i < NUM; i++){
            calcSum();
        }
    }
}

2.4.1 -XX:+PrintCompilation

  可知道某个方法是否被编译过，该参数要求虚拟机在即时编译时将被编译成本地代码的方法名打印出来。（其中，带有“%”的输出说明是由回边计数器触发的OSR编译）

VM option 1 +PrintCompilation
	310	1	java. lang.String: :charAt (33 bytes)
	329	2	org. fenixsoft.jit. Test: :calcSum (26 bytes)
	329	3	org. fenixsoft.jit. Test: : doubleValue(4 bytes)
	332	1%	org. fenixsoft.jit. Test: :main @ 5 (20 bytes)

从上面代码清单输出的确认信息中可以确认main()、calcSum()和doubleValue()方法已经被编译。

2.4.2 -XX:+PrintInlining

加上参数-XX:+PrintInlining要求虚拟机输出方法内联信息

VM option' +PrintCompilation'
VM option' +PrintInlining'
	273	1	java . lang .String::charAt (33 bytes)
	291	2	org. fenixsoft.jit. Test::calcSum (26 bytes)
		@	9	org. fenixsoft.jit. Test: :doubleValue	inline (hot)
	294	3	org. fenixsoft.jit. Test: :doubleValue (4 bytes)
	295	1%	org. fenixsoft. jit. Test: :main @ 5 (20 bytes)
		@	5	org. fenixsoft.jit. Test: :calcSum	inline (hot)
		@	9	org. fenixsoft. jit . Test: :doubleValue	inline (hot)

可以看到，doubleValue方法已经内联到calaSum方法中了。


三、编译优化技术

虚拟机团队把对代码的优化措施都集中在了即时编译器中。

3.1 优化技术概览

3.1.1.编译器策略（compiler tactics）

  • 延迟编译(delayed compilation)
  • 分层编译(tiered compilation)
  • 栈上替换(on-stack replacement)
  • 延迟优化(delayed reoptimization)
  • 静态单赋值表示(static single assignment representation)

3.1.2.基于性能监控的优化技术(profile-based techniques)

  • 乐观空值断言(optimistic nullnuess assertions)
  • 乐观类型断言(optimistic type assertions)
  • 乐观类型增强(optimistic type strengthening)
  • 乐观数组长度增强（optimistic array length strengthening）
  • 裁剪未被选择的分支（untaken branch pruning）
  • 乐观的多态内联（optimistic N-morphic inlining）
  • 分支频率预测（branch frequency prediction）
  • 调用频率预测(call frequency prediction)

3.1.3.基于证据的优化技术(proof-based techniques)

  • 精确类型推断(exact type inference)
  • 内存值推断（memory value inference）
  • 内存值跟踪（memory value tracking）
  • 常量折叠（constant folding）
  • 重组（reassociation）
  • 操作符退化(operator strength reduction)
  • 空值检查消除（null check elimination）
  • 类型检测退化(type test strength reduction)
  • 类型检测消除(type test climination)
  • 代数简化(algebraic simplification)
  • 公共子表达式消除(common subexpression elimination)

3.1.4.数据流敏感重写（flow-sensitive rewrites）

  • 条件常量传播(conditional constant propagation)
  • 基于流承载的类型缩减转换(flow-carried type narrowing)
  • 无用代码消除(dead code elimination)

3.1.5.语言相关的优化技术(language-specific techniques)

  • 类型继承关系分析(class hicrarchy analysis)
  • 去虚拟化(devirtualization)
  • 符号常量传播(symbolic constant propagation)
  • 自动装箱消除(autobox elimination)
  • 逃逸分析(escape analysis)
  • 锁消除(lock elision)
  • 锁膨胀(lock coarsening)
  • 消除反射(de-reflection)

3.1.6.内存及代码位置变换(memory and placement transformation)

  • 表达式提升(expression hoisting)
  • 表达式下沉(expression sinking)
  • 冗余存储消除(redundant store elimination)
  • 相邻存储合并(adjacent store fusion)
  • 交汇点分离(merge-point splitting)

3.1.7.循环变换(loop transformations)

  • 循环展开（loop unrolling）
  • 循环剥离(loop peeling)
  • 安全点消除(safepoint elimination)
  • 迭代范围分离(iteration range splitting)
  • 范围检查消除(range check elimination)
  • 循环向量化(loop vectorization)

3.1.8.全局代码调整（global code shaping）

  • 内联(inlining)
  • 全局代码外提(global code motion)
  • 基于热度的代码布局(heat-based code layout)
  • Switch调整（switch balancing）

3.1.9.控制流图变换(control flow graph transformation)

  • 本地代码编排(local code scheduling)
  • 本地代码封包(local code bundling)
  • 延迟槽填充(delay slot filling)
  • 着色图寄存器分配(graph-coloring register allocation)
  • 线性扫描寄存器分配(linear scan register allocation)
  • 复写聚合(copy coalescing)
  • 常量分裂(constant splitting)
  • 复写移除(copy removal)
  • 地址模式匹配(address mode matching)
  • 指令窥空优化(instruction peepholing)
  • 基于确定有限状态机的代码生成(DFA-based code generator)

3.1.10 优化技术应用实例

static class B
{
	int value;
	final int get()
	{
		return value;
	}
}
public void foo()
{
	y=b.get();
	//...do stuff
	z=b.get();
	sum=y+z;
}

  首先需要明确的是，这些代码优化变换是建立在代码的某种中间表示或机器码之上，绝不是建立在Java源码之上的，为了展示方便，使用了Java语言的语法来表示这些优化技术所发挥的作用。

第一步：进行方法内联

主要目的：

  • 去除方法调用的成本（如建立栈帧等）
  • 为其他优化建立良好的基础

  方法内联膨胀之后可以便于在更大范围上采取后续的优化手段，从而获得更好的优化效果。因此，各种编译器一般都会把内联优化放在优化序列的最靠前位置。、

public void foo()
{
	y=b.value;
	//...do stuff
	z=b.value;
	sum=y+z;
}

第二步：进行冗余访问消除

  假设中间注释掉的“do stuff…”所代表的的操作不会改变b.value的值，那就可以把“z=b.value”替换为“z=y”，因为上一句“y=b.value”已经保证了变量y与b.value是一致的，这样就可以不再去访问对象b的局部变量了。如果把b.value看作是一个表达式，那也可以把这项优化看成是公共子表达式消除。

public void foo()
{
	y=b.value;
	//...do stuff
	z=y;
	sum=y+z;
}

第三步：进行复写传播

  因为在这段程序逻辑中并没有必要使用一个额外的变量“z”，它与变量“y”是完全相等的，因此可以使用“y”来代替“z”。

public void foo()
{
	y=b.value;
	//...do stuff
	y=y;
	sum=y+y;
}

第四步：进行无用代码消除

  无用代码可能是永远不会被执行的代码，也可能是完全没有意义的代码，因此，它又形象地称为“Dead Code”，在上述代码清单中，“y=y”是没有意义的，把它消除后的程序代码为：

public void foo()
{
	y=b.value;
	//...do stuff
	sum=y+y;
}

  经过四次优化后，所得到的的代码与开始时的代码所达到的效果是一致的，但是前者比后者省略了许多语句（体现在字节码和机器码指令上的差距会更大），执行效率也会更高。

3.2 公共子表达式消除

含义：如果一个表达式E已经计算过了，并且从先前的计算到现在E中所有变量的值都没有变化过，那E的这次出现就成了公共子表达式。

  对于这种表达式没有必要再花时间计算直接用前面的结果替换，如果这种优化仅限于程序的基本块内，便称为 局部公共子表达式消除，如果这种优化的范围涵盖了多个基本块，那就称为 全局公共子表达式消除。


3.3 数组边界检查消除

  Java语言中访问数组元素foo[i]的时候系统将会自动进行上下界的范围检查，即检查i必须满足i>=0&&i<foo.length这个条件，否者将抛出一个运行时异常：java.lang.ArrayIndexOutOfBoundsException。

  • 每次数组元素的读写都带有一次隐含的条件判定操作，对拥有大量数组访问的代码是一种性能负担

  • 如果编译器只要通过数据流分析就可以判断循环变量永远不会溢出，那就可以消除数组的上下界检查【尽可能把运行期检查提到编译期完成】

隐式异常处理：在出现异常时才处理

以Java伪代码来表示虚拟机访问foo.value的过程如下：

if(foo!=null)
{
	return foo.value;
}
else
{
	throw new NullPointException();
}

在使用隐式异常优化之后，虚拟机会把上面伪代码所表示的访问过程变为如下伪代码。

try
{
	return foo.value;
}
catch(segment_fault)
{
	uncommon_trap();
}

虚拟机会注册一个Segment Fault信号的异常处理器(伪代码中的uncommon_trap()），这样try中不出现异常就不会额外判断一次try语句中的内容是否空指针异常，代价就是若真的出现异常，必须转入异常处理器并抛出NullPointException异常，这个过程必须从用户态转到内核态处理，结束后再返回到用户态，速度远比一次判空慢。HotSpot会根据运行期收集到的Profile信息自动选择最优方案。

3.4 方法内联

  • 方法内联能消除方法调用的成本
  • 方法内联能为其他优化手段建立良好的基础

方法内联的行为看上去很简单，不过是把目标方法的代码“复制”到发起调用的方法之中，避免发生真实的调用而已

   java默认的方法就是虚方法，但是虚方法有时需要在运行时才能确定调用的版本。为了解决虚方法的内联，可以使用"类型继承关系分析"(CHA)技术，遇到虚方法会向CHA查询此方法在当前程序下是否有多个目标版本可供选择，如果只有一个版本则可以内联，这种内联属于激进优化，需要预留一个"逃生门"，称为守护内联。如果程序的后续执行过程中，虚拟机一直没有加载到会令这个方法的接受者的继承关系发生变化的类，那这个内联优化的代码就可以一直执行下去，但如果加载了导致继承关系发生变化的新类，那就需要抛弃已经编译的代码，退回到解释状态执行，或者重新进行编译。

  如果CHA查询出来的结果有多个版本，则编译器还可以使用内联缓存来完成方法内联，这是一个建立在目标方法正常入口之前的缓存，它的工作原理大致是：在未发生方法调用之前，内联缓存为空，当第一次调用发生之后，缓存记录下方法接收者的版本信息，每次调用都比较接收者版本，如果版本一致可以继续存在，否则取消内联，查找虚方法表进行方法分派

3.5 逃逸分析

  • 逃逸分析并不是直接优化代码的手段，而是为其他代码优化手段提供依据的分析技术
  • 逃逸分析的基本行为就是分析对象动态作用域：当一个对象在方法中被定义后，它可能被外部方法所引用，称为 方法逃逸；甚至还有可能被外部线程访问到，称为 线程逃逸。

  如果能证明一个对象不会逃逸到方法或线程之外，则可以为这个变量进行一些高效的优化:

  • 栈上分配
    如果证明一个对象不会逃逸到方法外面，可以让这个对象在栈上分配内存，对象所占用的内存空间就会随栈帧出栈而销毁，减少gc压力；

  • 同步消除
    线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那这个变量的读写肯定就不会有竞争，可以对这个变量实施同步消除；

  • 标量替换

标量(Scalar)是指一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型都无法分解，它们可以成为标量。相对的，如果一个数据可以继续分解，他就称作聚合量(Aggregate)，对象就是典型的聚合量。如果把一个对象拆散，根据程序访问的情况，将其使用到的成员变量恢复原始类型来访问就叫做标量替换。如果逃逸分析证明一个对象不会被外部访问，并且这个对象可以被拆散的话，那程序执行时就可能不创建这个对象，直接创建若干成员变量来代替。将对象拆分后，除了可以让对象的成员变量在栈上分配和读写之外，还可以为后续进一步优化手段创造条件。

四、Java与C/C++编译器的对比

  Java与C/C++的编译器对比代表了最经典的即时编译器与静态编译器的对比

4.1 Java虚拟机的即时编译器相较于C/C++静态编译器的性能

劣势：

  • 第一，即时编译器运行占用的是用户程序的运行时间，具有很大的时间压力，它能提供的优化手段也严重受制于编译成本。

  • 第二，Java语言是动态的类型安全语言，这就意味着要由虚拟机来确保程序不会违反语言语义或访问非结构化内存

  • 第三，Java语言中虽然没有virtual关键字，但是使用虚方法的频率却大于C/C++，这意味运行时对方法接收者进行多态选择的频率要大于C/C++语言，也意味着即时编译器在进行一些优化时的难度要大于C/C++的静态优化编译器

  • 第四，Java语言是可以动态扩展的语言，编译器不得不时刻注意并着类型的变化而在运行时撤销或重新进行一些优化

  • 第五，Java语言中对象的内存分配都是在堆上进行的，只有方法中的局部变量才能在栈上分配。而C/C++的对象则有多种内存分配方式，既能在堆上分配，又能在栈上分配

优势：

  • 开发效率得到提高

  • 在C/C++中别名分析的难度远高于java

  • C/C++编译器所有优化都在编译器完成，以运行期性能监控为基础的优化措施它都无法进行


五、扩展：解释执行与编译执行

编程语言：

  • 低级语言：机器语言、汇编语言
  • 高级语言：C、C++、java、python等
语言 执行方式
机器语言 最底层的语言，直接执行
汇编语言 通过汇编器翻译成机器指令后执行，一条汇编指令，对应着一条机器指令。
高级语言编程的程序 编译执行：程序语句先通过编译器（负责将一条语句翻译成多条机器指令）翻译成机器指令然后执行；
解释执行：程序语句逐条被解释器解释执行，不需要编译成机器指令；
编译和解释相结合：程序先被编译成字节码文件，然后字节码被解释器解释执行。

  不同平台识别的机器指令格式是不同的，因此编译执行的语言如C的代码需要在对应平台的编译器中编译成对应的机器指令才能执行而想python这种编译加解释的语言，其被编译成的字节码文件是Python虚拟机的指令，只要此平台安装了Python虚拟机，该字节码文件就能被执行。

标签
虚拟机
代码优化
编译程序
编译器优化
阈值
字节码
jit编译器
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!