|
|
@ -167,7 +167,7 @@ HotSpot 内置了多个 JIT 即时编译器,C1 和 C2,之所以引入多个 |
|
|
|
|
|
|
|
|
|
|
|
再说 Dalvik 和 ART。 |
|
|
|
再说 Dalvik 和 ART。 |
|
|
|
|
|
|
|
|
|
|
|
在官方文档上,已经没有 Dalvik 相关的信息了,Android 5 后,ART 全面取代了 Dalvik。Dalvik 使用 JIT 而 ART 使用 AOT。AOT 和 JIT 的不同之处在于,JIT 是在运行时进行编译,是动态编译,并且每次运行程序的时候都需要对 odex 重新进行编译;而 AOT 是静态编译,应用在安装的时候会启动 dex2oat 过程把 dex 预编译成 oat 文件,每次运行程序的时候不用重新编译。另外,相比于 Dalvik,ART 对 GC 过程也进行了改进,只有一次 GC 暂停,而 Dalvik 需要两次,而且在 GC 保持暂停状态期间并行处理。AOT 解决了应用启动和运行速度问题的同时也带来了另外两个问题,一个是应用安装和系统升级之后的应用安装时间比较长,二是优化后的文件会占用额外的存储空间。在 Android 7 之后,JIT 回归,形成了 AOT/JIT 混合编译模式,这种混合编译模式的特点是:应用在安装的时候 dex 不会被编译,应用在运行时 dex 文件先通过解释器执行,热点代码会被识别并被 JIT 编译后存储在 Code cache 中生成 profile 文件,再手机进入 IDLE(空闲)或者 Charging(充电)状态的时候,系统会扫描 App 目录下的 profile 文件并执行 AOT 过程进行编译。这样一说,其实是和 HotSpot 有点内味。 |
|
|
|
HotSpot 是基于栈结构的,而 Dalvik 是基于寄存器结构。在官方文档上,已经没有 Dalvik 相关的信息了,Android 5 后,ART 全面取代了 Dalvik。Dalvik 使用 JIT 而 ART 使用 AOT。AOT 和 JIT 的不同之处在于,JIT 是在运行时进行编译,是动态编译,并且每次运行程序的时候都需要对 odex 重新进行编译;而 AOT 是静态编译,应用在安装的时候会启动 dex2oat 过程把 dex 预编译成 oat 文件,每次运行程序的时候不用重新编译。另外,相比于 Dalvik,ART 对 GC 过程也进行了改进,只有一次 GC 暂停,而 Dalvik 需要两次,而且在 GC 保持暂停状态期间并行处理。AOT 解决了应用启动和运行速度问题的同时也带来了另外两个问题,一个是应用安装和系统升级之后的应用安装时间比较长,二是优化后的文件会占用额外的存储空间。在 Android 7 之后,JIT 回归,形成了 AOT/JIT 混合编译模式,这种混合编译模式的特点是:应用在安装的时候 dex 不会被编译,应用在运行时 dex 文件先通过解释器执行,热点代码会被识别并被 JIT 编译后存储在 Code cache 中生成 profile 文件,再手机进入 IDLE(空闲)或者 Charging(充电)状态的时候,系统会扫描 App 目录下的 profile 文件并执行 AOT 过程进行编译。这样一说,其实是和 HotSpot 有点内味。 |
|
|
|
|
|
|
|
|
|
|
|
#### JVM 是如何执行方法调用的? |
|
|
|
#### JVM 是如何执行方法调用的? |
|
|
|
|
|
|
|
|
|
|
@ -197,7 +197,7 @@ JVM 也提供了内联缓存来加快动态绑定,它能够缓存虚方法调 |
|
|
|
|
|
|
|
|
|
|
|
#### JVM 是如何实现泛型的? |
|
|
|
#### JVM 是如何实现泛型的? |
|
|
|
|
|
|
|
|
|
|
|
除了泛型擦除,我还真的没啥可讲的了,毕竟也就只有这点东西。 |
|
|
|
Java 中的泛型不过是一个语法糖,在编译时还会将实际类型给擦除掉,不过会新增一个 checkcast 指令来做编译时检查,不过类型不匹配就抛出 ClassCastException。 |
|
|
|
|
|
|
|
|
|
|
|
#### JVM 是如何实现异常的? |
|
|
|
#### JVM 是如何实现异常的? |
|
|
|
|
|
|
|
|
|
|
|