在图 6-57 中：
右边是 C/C++ 源码编译成目标机器码后，该目标机器码编译，运行时只和目标的操作系统和相关库有关。
而 Dex/Java 字节码虽然也编译成目标机器码，但是它的编译和运行不仅仅依赖操作系统，还依赖具体的虚拟机实现。比如Dex字节码编译成机器码的话就依赖ART虚拟机。
这个道理很容易理解，但是也很容易被忽视。很多人以为 Java 字节码编译成机器码后就能和那些 C/C++ 编译得到的机器码一样无所羁绊地直接在OS上运行了，殊不知在Java字节码编译为机器码的过程中，虚拟机会添加一些必要和特殊的指令，使得得到的机器码在运行过程中实际上离不开虚拟机的管控。这里不妨举一个例子加以说明。
- Java虚拟机的垃圾回收器做对象标记前，往往会设置一个标志，表示自己要做对象标记了。
- 其他线程运行时要经常检查这个标志，发现这个标志为true时，这些线程就得等待，好让垃圾回收器能安全地做对象标记。否则的话，垃圾回收器一边做对象标记，其他线程同时又去创建对象或更改对象间的引用关系，这将导致对象标记不准确，影响垃圾回收。
显然，程序员在代码中是不会主动加上这个检查标记的动作。实际上，这是由编译器来主动完成的。它会在两个地方添加标记检查指令，一个是在 Entry 基本块里，另一个是在 loopheader 基本块里。
Java 字节码编译得到的机器码是离不开虚拟机的，它的编译也依赖与具体的虚拟机实现。
Android 在 Dalvik 时代采用的是 Java 虚拟机技术中较为成熟的 Just-In-Time（即时编译， 简写为 JIT）编译方案，JIT 会将热点 Java 函数的字节码转换成机器码，这样可提升虚拟机的运行速度。而 Android 虚拟机换为 ART 后，Google 最初却非常激进地抛弃了 JIT，转而采用了 Ahead-Of-Time（预编译，简写为 AOT）编译方案。AOT 导致系统在安装应用程序之时就会尝试将 APK 中大部分 Java 函数的字节码转换为机器码，其尽一切可能提升虚拟机运行速度的努力用心良苦。但 AOT 却带来了应用程序安装时间过长，编译生成的 oat 文件过大等一系列较为影响用户体验的副作用。为此，Android 在 7.0（Nougat）中对 ART 虚拟机进行了改造，综合使用了 JIT、AOT 编译方案，解决了纯 AOT 的弊端，同时还达到了预期目标。
————————————————
[深入理解ark虚拟机] https://blog.csdn.net/lyabc123456/article/details/134956749
