Android Runtime（ART）机制与 RISC-V64 支持研究（v2.1-public）

摘要

• ART 的运行体系可以沿一条真实调用串起来：zygote 建立 Runtime 并装载 boot image/vdex/oat，类加载把 DEX 链接成可执行入口，未编译方法落 nterp、按热度进入 JIT/AOT；本报告以 ZygoteInit.java:856 的 "start-system-server".equals(argv[i]) 为纵切案例，逐层追到 RISC-V64 机器码与回退路径 [S05][S23][S32][S39]。
• 该案例必须先分清两条正交的分派轴：调用点是否被编译并内建（kStringEquals，RV64 以 8 字节 Ld 批量比较），以及 callee 的 ArtMethod 入口（AOT/JIT/nterp/bridge）。只有“未内建且 callee 未编译”时才由解释器逐条执行 libcore 的 Java 循环，且循环每轮有两处 @FastNative 的 charAt（不是“每字符一次”）；性能差异主要由这两轴共同决定 [S12][S13][S17][S21]。
• RISC-V64 自 2023-01 进入公开 ART：Android 14 只有“解释器被显式排除”的骨架，Android 15 才形成完整后端；android17-release（26Q2）处于维护期，剩余缺口集中在 RVV codegen 未实现、GC 无 marking register、JIT 的 fast/pattern 路径仅 arm64、intrinsics 缺 CRC32/FP16 [S30][S33][S34]。
• “支持”必须分四层陈述：源码落地→构建/测试验证（公开记录多为 host-only，少数 target）→release 分支包含（以祖先关系判定）→产品可用（本轮未见公开承诺）；公开 main 自 2025-03-26 冻结，把 main 当“最新”会系统性低估 2025 年之后的能力 [S01][S33]。
• 全部结论锚定公开 commit；上游测试记录只作外部记录转述，本报告不含本人实测；性能内容均为机制解释与待验证假设（M1–M9），无虚构数字 [S01][S33][S34]。

背景与现状

ART 的位置与组件。 ART 是 Android 的 Java 运行时，随 APEX（com.android.art）更新。它在进程内的建立以 JNI_CreateJavaVM（runtime/jni/java_vm_ext.cc:1237）为入口，经 Runtime::Create（runtime/runtime.cc:1007）与 Runtime::Init（:1625）构造 gc::Heap（boot image 的装载就发生在 Heap 构造函数内，heap.cc:520 → ImageSpace::LoadBootImage）、fault manager、JavaVMExt、主线程与 ClassLinker（InitFromBootImage，:1351），再由 Runtime::Start（:1098）完成 root clinit、运行期 native 注册与 JIT 创建。应用进程由 zygote fork 得到，boot image 是 PROT_READ|PROT_WRITE + MAP_PRIVATE 的写时复制映射：未写页在 fork 后共享物理页，重定位/入口修正会弄脏私有副本；fork 前后分别执行 Runtime::PreZygoteFork（:869）与 InitNonZygoteOrPostFork（:1265）[S05][S07][S08][S25]。

产物与执行形态。 dex2oat 产出三类文件：vdex（原始 DEX + checksum + verifier deps + 类型查找表）、oat（编译代码 + 元数据 + stack map + boot classpath 键）、art image（堆对象快照与入口点/stub 地址）。a17r 的 vdex 已经没有 quickening 段，过滤器名 quicken 只作兼容告警并映射为 verify（compiler_filter.cc:181-184）；把 vdex 讲成“quickening 缓存”是过时说法 [S32][S36]。运行期执行形态由三层条件共同决定：编译过滤器/profile 决定哪些方法有 AOT 代码（libartbase/base/compiler_filter.h:34）；CanRuntimeUseNterp() 决定未编译方法能否用 nterp（nterp.cc:61-75）；JIT 的 MaybeEnqueueCompilation（jit.cc:1747）决定热度触发后的编译类型。任何“某方法一定跑在 X 引擎”的断言都必须给出这三层条件 [S23][S28][S32]。构建与部署侧，com.android.art 以 APEX 形式更新，设备开机窗口由 odrefresh 产出/校验引导镜像与其 oat/vdex（26Q2 的主镜像和 mainline 默认过滤器都是 speed-profile，odrefresh.cc:130/133），artd 负责运行期的 dexopt/工件管理；这两条链路决定了“设备上哪些方法有 AOT 代码”这一常被忽略的前提 [S32]。测试设施方面，test/ 的 run-test、TEST_MAPPING 的 host gtest 与 tools/buildbot-* 的 Cuttlefish/VM 流程构成可见的验证面；本报告只引用这些设施与上游记录，不把它们当作本人实测 [S37]。

分支模型（2025 年的变化）。 公开 main 自 2025-03-26 冻结在 6484611f（tree 688a2326… 与官方网页一致），开发转入 release 列车：25Q2（android16-release = android-16.0.0_r1/r2）、25Q3（qpr1 = r3）、25Q4（qpr2 = r4）、26Q2（android17-release = android-17.0.0_r1）；android17-security-release 不是 17 release 的后代（两者 merge-base 为 d9ee3abab2，安全线只多两个非 RISC-V 提交）。截至 2026-10-19，公开 refs 中没有 android18/26Q4 分支 [S01][S33]。

RISC-V64 的现状速览。 2023-01 起，Alibaba（Lifang Xia）与 Google（Ulya Trafimovich、Jaeheon Yi）把 RV64 作为新 InstructionSet 接入；2023 年补汇编器、codegen、JNI、nterp、intrinsics 与 oat 重定位；2024 年补 C/Zba/Zbb/Zbs、简化器与字符串/数学内建；2025 年进入维护与“向量寄存器分配 part 1”等前沿基础设施。到 26Q2，riscv64 专属源码约 60 文件（汇编器约 7900 行、codegen 约 7400 行、intrinsics 约 5900 行、170 个内建实现），并配有 458-checker-riscv64-* 用例与 Cuttlefish/Orange Pi 的测试记录；同时有三处“源码存在≠能力可用”的反例：nterp 早期只是 unimp 桩、RVV 只有汇编器与寄存器分配（向量 codegen 仍 FATAL）、GC 无 marking register [S11][S12][S30][S33][S34]。

研究基线与观察身份。 主 pin 为 android17-release b753cf97923c3695338d21466fa14c57b480a59a；libcore 与 frameworks/base 分别取其 android17-release tip（4ebfb391…、94b4c163…）。所有 ART 行号以主 pin 工作树为准。观察身份分四级：源码确证（本报告主体）、可复现但未执行（命令）、外部测试记录（上游提交信息中的 Test 步骤，非本报告实测）、本人实测（本报告无——未上板、未构建）。因此下文不出现任何实测性能数字；涉及性能处只给机制、观测口径与正确性门 [S01][S27]。

技术详解

本章以一条真实调用（String.equals）为主线组织：4.1 案例与基线 → 4.2 启动/产物/类加载 → 4.3 解释器 → 4.4 编译管线 → 4.5 RV64 后端 → 4.6 GC → 4.7 线程与内存序 → 4.8 JNI/ABI → 4.9 演进与支持分层 → 4.10 优化地图。

第 1 章（4.1）案例与基线：一次 String.equals 的调用点与执行路径

本章是重写版的“纵切案例”。它先把一条真实调用放回启动链（图 1），再把“调用点是否内建”与“callee 走哪个入口”拆成两条正交的分派轴（图 2），给后续各章提供统一参照。所有行号以 ART android17-release b753cf97、libcore/frameworks 各自 android17-release pin 为准；本报告未运行设备。

图 1： 案例调用在启动链中的位置（来源：ART a17r 的 runtime.cc/java_vm_ext.cc 与 frameworks ZygoteInit.java、AndroidRuntime.cpp、app_main.cpp，[S05][S23][S24][S48]，本项目绘制）。读图要点：先建立 Runtime（Heap 内装载 boot image，ClassLinker 接管），再执行 root clinit 并启动 JIT，最后进入 ZygoteInit.main 的参数解析；案例的 equals 调用就发生在参数解析循环里。main 后半段才创建 ZygoteServer、fork system_server 并进入 runSelectLoop；zygoteInit/nativeZygoteInit 是子进程初始化函数，不属于 main 的 fork 循环。图只画顺序，不画分派；分派见图 2。

4.1.1 为什么选这条案例

String.equals 是启动与日常运行中常见的字符串比较方法（本报告不引用“频率排名”这类无公开依据的说法）。选择它作为样本，是因为它同时满足四个可验证条件：

1. 有真实调用点：ZygoteInit.main 解析 zygote 启动参数时执行 "start-system-server".equals(argv[i])（frameworks/base android17-release，core/java/com/android/internal/os/ZygoteInit.java:856）[S23]。
2. 同一个调用点存在“内建/非内建”两种可能：ART 把 Ljava/lang/String;.equals(Ljava/lang/Object;)Z 登记为内建（runtime/intrinsics_list.h:214）[S13]；是否在本调用点生效取决于调用者是否被编译以及编译器是否把该 invoke 识别为内建（4.1.4）。
3. callee 本身有“编译/未编译”两种状态：libcore 的 String.equals 源码是纯 Java 循环（String.java:1660 起，循环在 :1675-1682）[S21]；但 boot-image 编译可尝试 StringEquals 的整方法 intrinsic body，因此不能从源码形态推断 callee 一定执行 Java 循环；它是否以 Java 循环执行取决于 callee 的入口点，而不是调用点是否内建。
4. 能落到 RV64 的两类真实代码：内建路径有 riscv64 专属 codegen（VisitStringEquals，intrinsics_riscv64.cc:1152）[S12]；解释路径中的 charAt 是 @FastNative native 方法（String.java:1273；实现 runtime/native/java_lang_String.cc:36），nterp 对 native 目标按 managed→quick code 的规则调用（mterp/riscv64/invoke.S 头注释）[S17][S19]。

4.1.2 版本基线（2026-10-19 复核）

观察身份与研究方法统一见附录 C（源码确证/可复现未执行/外部测试记录/本人实测四级；本报告无本人实测）。

4.1.3 端到端链路：从进程入口到这次调用

把这次 equals 放回启动链（图 1），顺序如下：

1. 进程入口与 JVM 创建：zygote 由 app_process 启动，AndroidRuntime::startVm 组装 JavaVMOption（AndroidRuntime.cpp:657）后调用 JNI_CreateJavaVM（:1208）；ART 侧入口是 runtime/jni/java_vm_ext.cc:1237，它调用 Runtime::Create（runtime/runtime.cc:1007）与 Runtime::Init（:1625），再 Runtime::Start（:1098）[S24][S06][S05]。
2. Runtime::Init 的关键对象：Monitor/ThreadList 之后构造 gc::Heap（:1894）；boot image 的装载在 Heap 构造函数内部（heap.cc:520 → ImageSpace::LoadBootImage，image_space.cc:3016），随后注册 fault manager 与 nterp 代码段、创建 JavaVMExt、Thread::Attach，最后由 ClassLinker::InitFromBootImage（:1351）接管镜像中的类与入口点 [S05][S07][S08]。
3. 镜像映射的真实权限：非压缩镜像走 MemMap::MapFileAtAddress(..., PROT_READ | PROT_WRITE, MAP_PRIVATE, ...)（image_space.cc:1383-1396）；压缩镜像先匿名映射 RW 再解压拷贝（:1407-1420）。因此镜像是可写私有映射（写时复制），不是“整块只读共享”：fork 后未写的物理页共享，重定位与 fork 前入口点修正会弄脏私有副本；这解释了下文“同一镜像、不同进程可写状态不同”的现象 [S07]。
4. Runtime::Start 与最初的 Java 执行：Runtime::Start 依次做 root clinits、注册运行期 native、按条件创建 JIT（:1149-1150）；Thread::FinishStartup 创建 main 线程 peer 并执行 root clinits，这是运行时内部最早的 Java 方法执行 [S05]。
5. Zygote 的 Java 层（注意函数作用域）：ZygoteInit.main（ZygoteInit.java:824）解析参数；命中 "start-system-server".equals(argv[i])（:856）时置位 startSystemServer；非懒预加载分支在 :889-896 调 preload()，随后 gcAndFinalize()、Zygote.initNativeState、new ZygoteServer（:909）、forkSystemServer（:912），父进程进入 runSelectLoop（:926）。另一函数 zygoteInit（:983）是子进程初始化入口，其中 :993 调 nativeZygoteInit()（声明 :1008）；其 JNI 实现把调用转给 AppRuntime::onZygoteInit（core/jni/AndroidRuntime.cpp:284-287、注册 :311-315），后者 ProcessState::startThreadPool() 启动 Binder 线程池（cmds/app_process/app_main.cpp:92-97）。childZygoteInit（:1003）明确跳过这条会启动 Binder threadpool 的初始化。因此不能把 :993 写成 main 末尾进入 fork 循环的调用 [S23][S24][S48]。
6. fork 前后：ZygoteHooks.preFork()（ZygoteHooks.java:198）→ nativePreFork()（:202）→ ZygoteHooks_nativePreFork（dalvik_system_ZygoteHooks.cc:255）→ Runtime::PreZygoteFork()（runtime.cc:869）：JIT pre-fork（:871）、等待单线程化、首次 fork 前修正已初始化类的 ArtMethod 入口点、heap_->PreZygoteFork()（:912）。子进程经 postForkChild（ZygoteHooks.java:230）→ nativePostForkChild（:294）→ Runtime::InitNonZygoteOrPostFork（runtime.cc:1265）。因此“案例调用会落到哪个入口”在 fork 前后也可能不同（入口点可被 JIT/配置改写）[S25][S26][S05]。
7. 调用点本身：ZygoteInit.main 里的 invoke-virtual 指向 String.equals(Object)。下一步不是直接“看 ArtMethod 入口”，而是先判断这个 invoke 是否被编译器内建——见 4.1.4。

4.1.4 两条正交的分派轴：调用点内建 vs callee 入口

两条分派轴与它们的组合见图 2。读图要点：轴 1 只看“这次 invoke 是否被编译期内建”，轴 2 只看“callee 的 ArtMethod 入口实际指向哪里”；“否”分支并不自动等于解释执行，callee 可能已有 AOT/JIT 代码；只有 callee 未编译且落入 nterp 时，才会执行 Java 循环并逐轮产生两处 charAt 调用（AOT intrinsic 方法体或 GenericJNI 回退）。

图 2： 调用点内建与 callee 入口的正交关系（来源：ART a17r 的 intrinsics_list.h/instruction_builder.cc/intrinsics_riscv64.cc 与 image_writer.cc，[S12][S13][S14][S20]，本项目绘制）。nterp 分支的 charAt 目标按 callee 的 quick entry 分两种：有 boot-image AOT intrinsic 方法体时落到该方法体；没有时才是 GenericJNI 回退。FastNative 不转 kNative；若走 JNI stub/GenericJNI，LRT 仍建立/弹出。

“调用点被内建”“callee 有编译代码”“callee 正在解释”是三个不同的问题，不能互相推导。

轴 1：调用点是否被内建（caller 侧）

若包含该调用的方法被优化编译器编译，且该 invoke 在编译期被识别为 kStringEquals（runtime/intrinsics_list.h:214，签名精确匹配），编译器在调用点直接生成内建序列（riscv64 为 VisitStringEquals，intrinsics_riscv64.cc:1152 起），不会经过 String.equals 的 ArtMethod 入口。若编译器未能识别（方法未解析、版本/选项不启用该内建等），该调用按普通 invoke 生成，转轴 2。轴 1 的结论只与“caller 的编译产物 + 本次 invoke 的识别结果”有关，与 callee 本身是否已编译无关。

轴 2：callee 的入口点（被调用方）

若调用点没有被内建（调用者未编译，或编译了但该 invoke 未内建），执行时读取 callee 的 ArtMethod 入口点，可能是：AOT quick code（boot image 中已编译）、JIT quick code（运行期编译完成、入口已替换）、nterp 入口（未编译且允许解释）、quick-to-interpreter bridge / switch 解释器（-Xint、nterp 不可用等）。

callee 若是已编译的 String.equals，不能无条件说它就是“Java 循环 + charAt”：① String.equals 是非 native 的 kStringEquals intrinsic，非 native Compile 在 method->IsIntrinsic() 时会尝试 TryCompileIntrinsic()（optimizing_compiler.cc:1142-1154；instruction_builder.cc:494-525 在无 simple IR 时仍可构造自 invoke；intrinsics_riscv64.cc:1141-1149 的 StringEquals 走 CreateNoCall），若通过 leaf 门（:1079-1084）可生成整方法 intrinsic body，此时不执行 Java 循环；②若走普通 DEX graph 编译，方法体才是 libcore 的 Java 循环，charAt 调用点可被 kStringCharAt 内建为 HArrayGet（instruction_builder.cc:2125、:2225；简化器 instruction_simplifier.cc:2859），循环内没有对 callee 的调用；③callee 若在 nterp 中执行，则按 libcore 的 Java 循环逐条解释；循环每轮仍有两处 charAt 调用（String.java:1675-1682），每处都是普通 invoke。nterp 在本 pin 没有运行期内建（invoke.S 的专门路径只处理 String.<init>，见 :119-130、:444），因此按 callee 的 quick entry 离开 nterp。String.charAt 虽声明为 @FastNative native 方法，但它在 intrinsics_list.h:112 登记为 kStringCharAt；native charAt 的 boot-image 编译走 OptimizingCompiler::JniCompile（:1235），其 intrinsic 路径在 optimizing_compiler.cc:1244-1277（TryCompileIntrinsic() 调用在 :1269），可生成真正的 AOT 方法体，而 image_writer.cc:1488-1495 明确不为 intrinsic native 方法写 JNI stub。因此，若该 boot image 已为它生成 AOT intrinsic 方法体，callee quick entry 就是编译后的方法体（普通 managed quick 调用，做 count/bounds/字符加载），不是 JNI 入口；thread.cc:4368-4381 也把“AOT-compiled String.charAt”与 GenericJni 路径区分开。只有当该方法没有 AOT intrinsic 代码（quick_code == nullptr，例如非 boot image、过滤器未覆盖、编译失败或产物未包含）时，image_writer.cc:3530-3534 才回退到 GenericJNI trampoline，再由 dlsym lookup 找到 String_charAt（4.8.3）。不能断言标准镜像必然已 AOT：具体产品是否编译了该方法体取决于实际 boot image/profile/过滤器/产物，本报告未测，故两轴表把它写成条件分支。若确实走到 JNI stub/GenericJNI，@FastNative 不转 kNative、不调 artJniMethodStart，但 LRT 仍按 !is_critical_native 的门建立/弹出（jni_compiler.cc:285-305、:519-524）[S19][S43]。

组合表（对“这次调用”逐个判定）

内建序列本身（当轴 1 为“是”时）：参数空检查（Beqz）→ 引用相等（Beq）→ klass_ 比较（两次 Loadwu，依赖 String 类对象不可移动，无读屏障）→ count 比较（Loadwu）→ 压缩标志/字符数换算 → 从 value_offset 起以 8 字节 Ld 批量比较（压缩时每轮 8 字节，非压缩时每轮 4 个字符）→ 返回 0/1（intrinsics_riscv64.cc:1152-1240；存储布局见 mirror/string.h:316-326）[S12][S16]。复杂度：比较长度相等时最坏需要扫描整串，仍是 O(n)；8 字节批处理降低的是常数因子，不改变最坏复杂度。

count 比较为什么成立（内部不变量，不是 Java 语义）：Java 的 String.equals 语义是“字符序列相等”，编码是实现细节。本 pin 能先比较 count（长度<<1 | 压缩标志）再比字节，依赖构造时的压缩规范化：例如 String::AllocFromModifiedUtf8 以 utf16_length == utf8_length 判 compressible（string.cc:254），其它构造/替换路径也按内容计算 compressible（string.cc:90、:129、:194、:217），并由 GetFlaggedCount 写入标志位（string.h:271-280）。因此同一字符序列必然得到同一 coder：长度相同但 coder 不同的两串不可能字符序列相等。RV64 内建的 count 比较（含 compression flag）正是利用这一内部不变量；不能把它写成“Java 规定编码不同返回 false”——这是实现层优化，若字符串实现允许非规范化表示，该比较就不再成立 [S16]。

4.1.5 失败与回退

• 参数为 null：语义返回 false；内建路径 Beqz(arg, return_false)，解释路径 instanceof String 为假，同样返回 false，都不抛异常。
• 长度或编码不同：返回 false；内建先比较 count，解释先比较 length()。
• 越界异常：equals 循环以 length() 为上界，正常不触发；charAt 自身的越界检查在被其它调用者使用时抛 StringIndexOutOfBoundsException（mirror::String::CharAt，string-inl.h:45 起；native 入口 java_lang_String.cc:36）[S16][S17]。
• 执行模式回退：CanRuntimeUseNterp() 为假（debuggable/-Xint/entry-exit stubs/异步异常等）→ 未编译方法起步于 switch 解释器（JIT 之后仍可能替换入口）；JIT 编译失败或去优化 → 回到解释器；callee 未编译时即使 caller 已编译，普通 invoke 也只会进入 callee 的解释入口（轴 2）。具体条件见 4.3/4.4。
• 内建失效：只影响“本次调用点”；callee 的编译状态与入口点独立（轴 2）。

4.1.6 观察方法与后续导览

成本与权衡（案例口径）：内建路径把比较变成调用点内的批量 load/比较，最坏仍 O(n)，但省去方法调用与循环解释开销；非内建且 callee 未编译时，每轮两处 charAt 是两次 quick 调用。若目标已有 AOT intrinsic 方法体，成本是普通 quick 帧、count/bounds 检查与字节加载；只有回退到 GenericJNI 时才有 JNI 帧、参数搬运、LRT 压/弹与返回检查。不能把“解释态 charAt”一概记成 JNI 边界。选择哪条由轴 1/轴 2 共同决定，不是“架构优劣”；代价是编译需要热度/profile/过滤器与代码缓存，且产物增加代码尺寸与构建时间。成本测量口径见 4.10，未测量不写数字 [S12][S28][S43]。

可复现（未执行）的最小观察集：oatdump --oat-file=<boot.oat> 看 String.equals 是否有 AOT 代码及其入口；logcat 过滤 JIT 日志看编译发生；profman --dump-info-for=<profile> 看该方法/其调用者是否进入 profile。设备前提与命令细节见 4.9。

后续：4.2 启动/产物/类加载；4.3 nterp（帧、invoke 层级、native 转换）；4.4 编译管线（profile/热度/JIT/AOT/IR/寄存器/stack map/OSR/去优化）；4.5 RV64 后端（ABI/指令选择/内建/RVV）；4.6 GC；4.7 线程与内存序；4.8 JNI/native；4.9 演进与支持分层；4.10 优化地图。

第 2 章（4.2）运行时建立与产物加载：zygote、boot image、DEX/OAT/VDEX 与类加载

本章回答三个问题：zygote fork 前后运行时到底改写了什么；启动时加载的 boot.art/oat/vdex 各自是什么、校验什么；一个类从 DEX 字节到“可执行入口点”经过哪些状态。所有行号以 ART android17-release b753cf97、libcore/frameworks 各自 android17-release pin 为准。本报告未运行设备，本章所有观察均为源码确证；命令均标注为可复现未执行。

4.2.1 fork 模型与对象所有权

zygote 的核心假设是“先把运行时和常用类一次性准备好，再 fork 共享”。这要求 fork 前把多线程状态收拢为单线程、把会弄脏共享页的工作提前做掉，fork 后只为子进程重建必要的线程与状态。

fork 前（父进程）：libcore 的 ZygoteHooks.preFork()（ZygoteHooks.java:198）调用 nativePreFork()（:202），进入 ART 的 ZygoteHooks_nativePreFork（runtime/native/dalvik_system_ZygoteHooks.cc:255），再到 Runtime::PreZygoteFork()（runtime/runtime.cc:869）。按源码顺序，它做四件事：

1. Jit::PreZygoteFork()（:871）——通知 JIT 进入 fork 前的安全状态；
2. 收紧线程列表：等待其他线程完成 Unregister，并 WaitUntilSingleThreaded()（:876-900 区段），这是“fork 只能发生在单线程进程”的运行时侧保证；
3. 首次 fork 时修正所有已初始化类的 ArtMethod 入口点：MakeInitializedClassesVisiblyInitialized + UpdateMethodsPreFirstForkVisitor（:902-911）——把类初始化完成后的入口点（trampoline → 真实代码/nterp）在共享页上一次性写好，避免每个子进程各自弄脏；
4. heap_->PreZygoteFork()（:912）与 PreZygoteForkNativeBridge()（:913）——堆与 native bridge 的 fork 前收尾 [S05][S25][S26]。

fork 后（子进程）：ZygoteHooks.postForkChild（ZygoteHooks.java:230）→ ZygoteHooks_nativePostForkChild（dalvik_system_ZygoteHooks.cc:294）→ Runtime::InitNonZygoteOrPostFork（runtime/runtime.cc:1265）。关键动作包括：native bridge 的卸载/初始化（:1273-1284）；child-zygote 的提前返回（只初始化 native bridge，其余交给 Java 侧，:1286-1293）；system_server 的应用信息注册与 profile 配置（:1297-1330 区段）；按属性 dalvik.vm.parallel-image-loading 创建最多 4 个 runtime 线程用于并行加载 app image（:1327-1350）；重置 GC 性能数据与 metrics（:1321-1322）；StartSignalCatcher()（:1364）；perfetto hprof 插件、odrefresh 统计上传（system_server）、JNI id 类型选择（debuggable=indices，否则 pointer，:1393-1397）以及最后启动调试器（:1407-1409）[S05][S25]。

对象所有权（谁活多久、谁持有谁）：

4.2.2 Runtime::Init 的顺序与 boot image 的装载/校验

启动装载与校验的整体关系见图 3。读图要点：磁盘上的四类产物（DEX/VDEX/OAT/ART image）各司其职；装载时先做镜像/oat/boot classpath 三重校验，再重定位并交给 Heap/ClassLinker；失败有三条分支（内存编译、跳过扩展 chunk、无镜像路径）。图下方的“案例落点”提醒：类在镜像里不等于方法已编译。

图 3： 启动装载与校验关系（来源：ART a17r 的 heap.cc/image_space.cc/class_linker.cc，[S07][S08][S32]，本项目绘制）。校验通过走“使用 boot image”分支；失败按 checksum/BCP/版本、扩展 chunk、无镜像三类进入不同兜底，不是同一条必经直线，也不保证所有失败都能成功启动。

Runtime::Init（runtime/runtime.cc:1625）的组件顺序在 4.1.3 已给出骨架；这里补“装载与校验”的细节，因为它决定了案例方法在启动后处于什么执行状态。

1. 镜像发现与映射：boot classpath 与镜像位置来自 -Xbootclasspath/-Ximage（framework 侧由 dalvik.vm.boot-image 映射，AndroidRuntime.cpp:783-784）[S24]；Heap 构造时调用 ImageSpace::LoadBootImage（image_space.cc:3016），BootImageLayout::Load 先校验镜像位置与 boot classpath 形状，再逐组件 ReadHeader → ValidateOatFile（image_space.cc:1791 起）。
2. 三类失败与兜底：镜像版本/oat checksum/boot classpath 任一不匹配，ValidateOatFile 报 "ValidateOatFile found checksum mismatch … (0x%x != 0x%x)" 一类错误；主镜像失败且允许内存编译（zygote 默认）时走 CompileBootclasspathElements 在内存里重建完整 boot image，否则整体失败；扩展镜像失败则跳过该 chunk（image_space.cc:2140-2204 区段）。镜像格式版本在 a17r 为 119（runtime/oat/image.cc:39），a16q2 为 118——跨版本互不兼容 [S07][S08]。
3. 入口点的两次改写：镜像生成时，未编译的 Java 方法写 nterp trampoline（需要 clinit 的写 resolution trampoline）；非 intrinsic 的 native 方法在 boot image 中写 JNI stub（image_writer.cc:1488-1495），而 intrinsic native 方法（如 String.charAt）经 OptimizingCompiler::JniCompile 的 intrinsic 路径生成 AOT 方法体（optimizing_compiler.cc:1244-1277，TryCompileIntrinsic 调用 :1269），只有 quick_code == nullptr 时才回退 GenericJNI trampoline（image_writer.cc:3530-3534）。镜像加载时 ClassLinker::AddImageSpace 把 nterp trampoline 原地改成 interpreter::GetNterpEntryPoint()（class_linker.cc:2332-2342，条件为 CanRuntimeUseNterp()），否则改回 quick-to-interpreter bridge。若根本无镜像（InitWithoutImage，class_linker.cc:699；调用点 runtime.cc:2173），则直接以 nterp 入口自建 trampoline（:914）[S08][S20]。
4. 首个 Java 执行：Runtime::Start → Thread::FinishStartup → RunRootClinits（4.1.3 的链条）。此处的类初始化是“真实 Java 代码第一次跑”的位置，String 等核心类的状态机也从这里开始进入 kInitialized/kVisiblyInitialized [S05]。

4.2.3 DEX、VDEX、OAT、ART image 的当前关系（含一处重要纠错）

四种产物的职责经常被写混。按 a17r 源码，准确关系是：

• DEX：输入字节码。标准 DEX 版本 035/037/038/039/040/041（libdexfile/dex/standard_dex_file.cc:29-40）；String.equals 的字节码就来自这里。CompactDex 已不在主线：25Q2 的树中仍有 compact_dex* 实现（4 个文件），25Q3（a16-qpr1 tip e5c642b5）已为 0——移除发生在 25Q2→25Q3 窗口 [S39]。
• VDEX：a17r 的 VdexFile 只有四个 section：kChecksumSection/kDexFileSection/kVerifierDepsSection/kTypeLookupTableSection（runtime/vdex_file.h:80-86）。kDexFileSection 存原始 DEX 字节，kVerifierDepsSection 存验证依赖（跨 dex 的可赋值性/字符串），kTypeLookupTableSection 是类型查找表 [S32]。
• OAT：编译后的机器码 + 元数据（方法头、stack map、boot classpath 键与 checksum 等），由 OatWriter 写出，relative_patcher 负责跨方法/跨 oat 的相对调用修补。
• ART image：堆对象快照（类对象、字符串常量、ArtMethod 等）+ 入口点与 stub 地址；不是代码本身，而是“已初始化好的对象图”。

a17r 的 VDEX 不承载 quickening。 在当前 pin 中：

// runtime/vdex_file.h:80-86（a17r）
enum VdexSection : uint32_t {
  kChecksumSection = 0,
  kDexFileSection = 1,
  kVerifierDepsSection = 2,
  kTypeLookupTableSection = 3,
  kNumberOfSections = 4,
};

没有任何 quickening section；解释器目录也没有对 quickened 指令的引用；dex2oat 的过滤器名 quicken 只剩兼容告警——libartbase/base/compiler_filter.cc:181-184 明确打印 “'quicken' is an obsolete compiler filter name … please use 'verify' instead”，并映射到 kVerify。历史注释里仍能看到 “unquickened dex” 字样（如 oat_file_manager.h:86），但它们不是现行数据通路 [S32][S36][S39]。

这个纠错直接影响两个常被误传的结论：其一，“解释器靠 vdex 里的 quickened 指令加速”在 a17r 不成立——nterp 用标准 DEX + 解释器缓存/内联缓存执行；其二，“vdex 只用于快速验证”也不完整——它同时保存了原始 DEX 本体（kDexFileSection），运行期类加载从 vdex/oat 打开的就是这份 DEX。VdexFile 对外提供 GetNumberOfDexFiles/GetDexChecksumAt/GetNextDexFileData 等访问器（vdex_file.h:167-273），镜像/oat 校验时用 checksum 与真实 DEX 对齐 [S32]。

4.2.4 类加载与状态机：从 FindClass 到可执行入口点

类加载的主链（runtime/class_linker.cc；行号已按 a17r 复核）：

FindClass（:3266）→ LookupClass 命中则 EnsureResolved（:3296），未命中 DefineClass（:3505）→ LoadClass（:4491，成员加载由 LoadClassHelper 完成）→ LoadSuperAndInterfaces（:3642）→ LinkClass（:6646：LinkSuperClass/LinkMethods/字段链接，LinkMethodsHelper 构建 vtable/IMT，成功后 SetStatus(kResolved) :6733）→ 首次主动使用时 InitializeClass（:5938）。状态机在 runtime/class_status.h:111-129：kLoaded → kResolved → kVerified → kInitializing → kInitialized → kVisiblyInitialized。EnsureResolved 的等待协议是“自旋 1000 次 + 1ms sleep + ObjectTryLock 防死锁”，并检测类初始化循环依赖（ThrowClassCircularityError，:2937-2939）[S08][S39]。

InitializeClass 的并发协议（JLS 12.4.2）：快路径无锁判断已初始化（:5947）→ ObjectLock<Class> 下重查 → 未验证先 VerifyClass（:5980）→ 状态为 kInitializing 且非本线程则 WaitForInitializeClass（:6037）→ 置 ClinitThreadId、kInitializing（:6062-6063）→ 递归初始化父类与默认方法接口 → 执行 <clinit> → kInitialized/kVisiblyInitialized（可见性由全线程 checkpoint 保证，注释见 class_status.h:102-110）[S08][S39]。

验证器的软失败会改变“何时可编译”：方法校验的 kSoftFailure/kTypeChecksFailure 在 AOT 下映射为 kRetryVerificationAtRuntime（运行期重验、方法不可编译）或 kVerifiedNeedsAccessChecks（class_linker.cc:5419-5425）；这正是“某些方法明明有 AOT 机会却只在运行期验证”的机制来源。分派则在链接期定表：虚调用经 vtable 入口（mirror/class-inl.h:531 的 FindVirtualMethodForVirtualOrInterface），接口调用走 iftable 逻辑；未解析调用由 art_quick_resolution_trampoline（riscv64 汇编 quick_entrypoints_riscv64.S:872，C++ 端 quick_trampoline_entrypoints.cc:1205）解析后跳转。异常语义在 ArtMethod::FindCatchBlock（art_method.cc:328）按 try item 匹配，编译代码的异常分派走 QuickExceptionHandler（quick_exception_handler.cc:146）[S08][S39]。

4.2.5 案例落点：String.equals 在启动后的真实状态

结合以上：String 类属于 boot classpath，其 ArtMethod 在镜像中已存在；String.equals 是否有 AOT 代码取决于 boot image 的编译配置（过滤器与 profile），没有 AOT 时其入口是 nterp（若允许）或 quick-to-interpreter bridge；String.charAt 是 native 方法，但也是 kStringCharAt intrinsic：若 boot image 为它生成了 AOT intrinsic 方法体，quick entry 指向该方法体；否则才回退 GenericJNI（image_writer.cc:3530-3534）。因此案例在启动后的第一次调用可能落在任一入口上，不能从“类在 boot image 里”推断“方法已编译/未编译”；具体要看该 boot image 的过滤器/profile/产物 [S08][S20]。fork 之后子进程复用的是同一份 COW 镜像映射，但入口点是否被 JIT 替换、nterp 是否可用（debuggable/-Xint）因进程配置而异——这就是 4.1 图 1 中分支判断的实际来源。

4.2.6 失败、回退与观察

• 镜像不匹配：版本/checksum/BCP 校验失败 → 内存编译或解释执行；错误串以 ValidateOatFile found checksum mismatch、Failed to match oat file checksum / Failed to match oat boot class path 为线索（image_space.cc）。
• 无镜像：InitWithoutImage 路径（class_linker.cc:699）以 boot classpath dex 建立类表，nterp trampoline 直接设为 nterp 入口（:914）。
• 类初始化失败：<clinit> 抛出异常 → 类置 kErrorResolved，后续使用得到 NoClassDefFoundError（由状态检查与异常传播共同保证）。
• VDEX 相关误判：不要再用 quickening 解释解释器性能；当前 pin 下应按“原始 DEX + verifier deps + 类型查找表 + OAT 代码/元数据 + 镜像对象图”理解产物。
• 可复现观察（未执行）：oatdump --image=<boot.art> 查看镜像/oat 与方法入口；logcat 搜索镜像校验相关错误串；profman 查看 profile 是否覆盖案例方法。设备与同版本工具是前提。

后续第 3 章进入解释器。

成本与权衡：镜像校验换启动安全（版本/checksum/BCP 三重比对），失败时的内存编译兜底换正确性但会显著拉长首次启动；vdex 保存原始 DEX 换“打开时无需全量重算”，代价是磁盘占用；fork 前把入口点与堆状态修好，换子进程共享 COW 页（未写页不复制）、避免每进程重复准备。每一项都是“启动时间/内存/安全”的取舍，具体数值需设备测量（未做）。

String.equals 在未编译时如何一字节一字节执行、charAt 如何转入 native；第 4 章进入编译流水线：这段代码如何被 profile 选中、如何生成 RV64 的 8 字节比较。

第 3 章（4.3）解释执行：nterp 的帧、分派、invoke 与 native 边界

本章回答：String.equals 未被编译时，nterp 如何执行它；一次 charAt 调用如何从解释器离开、落到 intrinsic quick 方法体或 GenericJNI 回退再回来；解释器在什么条件下根本不启用。行号均以 ART android17-release b753cf97 为准；未运行设备。

4.3.1 解释器的现状：只有一个快解释器

公开 ART 中的经典 mterp 已于 2021 年被整体删除（提交 e4f983c808 "Remove mterp."，Nicolas Geoffray；该提交不在 android12 分支、在 android13 及以后）[S41]。当前解释执行只有两种形态：

• nterp：按架构提供的汇编快解释器（runtime/interpreter/mterp/<arch>/；riscv64 目录因从未有过经典 mterp 而直接用架构名），通过 python 模板生成，handler 以 computed-goto 组织；
• C++ switch 解释器：runtime/interpreter/interpreter_switch_impl0.cc 起的实现，作为 nterp 不可用时的回退。

nterp 的启用判定是两层：IsNterpSupported()（runtime/interpreter/mterp/nterp.cc:38-59）在配置层判断——riscv64 分支直接 return true，arm/arm64 还要求 kReserveMarkingRegister && !kUseTableLookupReadBarrier；CanRuntimeUseNterp()（:61-75）在进程层判断——非 debuggable、无 entry/exit stubs、非 InterpretOnly、非 AOT 编译器、无异步异常待决、JIT 非 JitAtFirstUse。任一不满足就回退 switch 解释器。方法级还有 CanMethodUseNterp()：native 方法、非 invokable、需要计数锁（MustCountLocks）、代理方法、以及帧尺寸超过 kNterpMaxFrame 的方法都不能用 nterp（runtime/nterp_helpers.cc:225-257 区段）[S18][S40]。

4.3.2 帧布局：一种“quick 栈帧 + 双数组”的混合结构

nterp 帧布局与 invoke 层级见图 4。读图要点：frame（ArtMethod**，即新 sp）指向低地址的 method 槽，向上依次是 out 参数、saved dex pc、previous frame、引用影子数组、dex 寄存器数组；callee-save 区在更高的地址，由序言先 INCREASE_FRAME NTERP_SIZE_SAVE_CALLEE_SAVES 留出。charAt 这类 @FastNative 调用从解释器离开时按 callee quick entry 走第②/③/④层：有 boot-image AOT intrinsic 方法体时落到该方法体（普通 quick 调用）；没有时才是 GenericJNI 回退（此时才有 JNI 帧/LRT）。

图 4： nterp 帧与调用路径（来源：ART a17r 的 nterp_helpers.cc、mterp/riscv64/main.S/invoke.S，[S19][S40]，本项目绘制）。帧内低地址是 method/out/dex pc/prev/双数组，callee-save 区在更高地址；invoke 第②层是 Nterp→managed ABI，不是 JNI native ABI。charAt 的 quick 目标可为 AOT intrinsic 方法体，也可在无代码时回退 GenericJNI。

nterp 的帧由两段组成：低地址是与 quick 调用约定兼容的解释器帧（method/out/dex pc/prev/双数组），高地址是 callee-save 区。NterpGetFrameSizeWithoutPadding（runtime/nterp_helpers.cc:153-171）给出的是总大小（加法与地址方向无关）：

总大小 = callee-save frame entry（NTERP_SIZE_SAVE_CALLEE_SAVES=192B）
       + num_regs*4 (dex 寄存器数组) + num_regs*4 (引用影子数组)
       + 8 (previous frame) + 8 (saved dex pc)
       + out_regs*4 (传出参数) + 8 (method)

地址从低到高则是：

frame/sp → method* (8B)
           out 参数 (out_regs*4，按指针大小向上对齐)
           saved dex pc (8B)
           previous frame (8B)
           refs 数组 (num_regs*4)
           regs 数组 (num_regs*4)
           callee-save 区 (192B，位于更高地址)

对应到 riscv64 汇编（runtime/interpreter/mterp/riscv64/main.S:422 起的 ExecuteNterpImpl 序言；invoke 路径 invoke.S:1374-1431）：先 INCREASE_FRAME 留出 callee-save 区并保存，再从当前 sp 向低地址减去解释器帧大小；sd a0,(sp) 把 ArtMethod* 放在新帧最低槽，xREFS 指向引用影子数组、xFP 指向 dex 值数组、xPC 是解释器的 dex 指令指针、xINST 是当前 16 位指令、xIBASE 是 handler 表基址；s7=refs/fp vreg 数、s8=ins 数、s9=spills 后、帧前 sp。CFI_DEFINE_DEX_PC_WITH_OFFSET 把 dex pc 暴露给栈展开器——调试与异常回溯依赖它 [S19][S40]。

读取函数与上述地址顺序一一对应：NterpGetReferenceArray = frame + 8(method) + RoundUp(out_regs*4,8) + 8(dex pc) + 8(prev frame)；NterpGetRegistersArray 在引用数组之上（+ num_regs*4）；NterpGetDexPC 从保存的 dex pc 槽减去指令基址（nterp_helpers.cc:189-212）。NterpFrameInfo 把同一布局换算成 QuickMethodFrameInfo，告知 GC/栈展开器需要保存哪些 callee-save 寄存器 [S40]。

进入 nterp 的序言有三条快路径（main.S:432-470）：零参数；全引用参数（检查 ART_METHOD_NTERP_ENTRY_POINT_FAST_PATH_FLAG_BIT 后把 a1.. 直接写入 xFP/xREFS）；实例方法零参数。当这些快路径不适用时才走慢路径：SPILL_ALL_ARGUMENTS → call NterpGetShorty → 按 shorty 把参数从机器寄存器搬进 dex 寄存器数组/引用数组。慢路径的成本只落在未命中快路径的调用上，不能写成“每次调用都走 shorty 慢路径” [S19][S40]。

4.3.3 分派与解析缓存

nterp 用 computed-goto：每个 opcode 的 handler 位于 artNterpAsmInstructionStart + opcode*步长，handler 末尾 FETCH_INST → GET_INST_OPCODE → GOTO_OPCODE（main.S:680 起的模板；riscv64 单套 handler 表，arm/arm64 为四套 16 KiB 对齐副本，见 CheckNterpAsmConstants）。解析结果用解释器缓存加速：InterpreterCache 是 256 项直接映射表（runtime/interpreter/interpreter_cache.h:54，索引为 (dex_pc_ptr >> kKeyLowBit) & 255），按 dex 指令指针缓存方法、字段偏移、类、字符串等解析结果。慢路径 C++ 函数在 nterp 代码结尾以 trampoline 暴露：nterp_get_method、nterp_get_static_field、nterp_get_instance_field_offset、nterp_get_class、nterp_allocate_object、nterp_load_object 等（main.S:661-672 的 NTERP_TRAMPOLINE 列表），对应 NterpGetMethod/NterpGetStaticField 等实现。慢路径解析会通过 UpdateHotness 给方法 +0xf 热度 [S18][S19][S40]。

4.3.4 invoke 的四个层级：什么时候留在 nterp，什么时候离开

riscv64 的 invoke.S 把调用分成清晰的层级（源码头注释 :10-33）[S19]：

1. nterp-to-nterp 快路径：若目标方法的 quick code 指针等于 ExecuteNterpImpl（try_nterp 宏，:670 起用 lla 比较），且方法带 ART_METHOD_NTERP_INVOKE_FAST_PATH_FLAG_BIT，则直接在 vreg 之间搬运参数、建立新 nterp 帧、跳到目标方法第一条指令的 handler。nterp_invoke_* 系列与 NterpToNterp* 标签（main.S:640-653）即此路径。这条路径没有 native 调用、没有 shorty 解析。
2. 全引用参数（Nterp → managed quick code）：目标不是 nterp，但参数全是对象引用时，按 managed ABI 布置——A0=ArtMethod*、实参从 A1 起，用 LWU 把每个 vreg 装进相应机器参数寄存器后 jalr 目标 quick code。这里不是 JNI native ABI；若目标 quick code 恰好是 GenericJNI（无 AOT intrinsic/编译代码的 native 回退），再由它把 managed 参数搬到 JNIEnv*/jobject 的 JNI 位置。
3. 零/单参数：窥探下一 opcode 判断返回值类型，必要时只解析 shorty；标量返回要处理 fa0 → a0 的搬运。
4. 完整 shorty 路径：多参数混合 float/double/long、或 invoke-polymorphic/custom 时，按 shorty 做完整的 managed ABI 参数布置，再 jalr quick code；polymorphic/custom 分别转 art_quick_invoke_polymorphic / art_quick_invoke_custom（:579、:596）。

这正是案例的执行细节：解释态下 String.equals 的循环每轮仍有两处 charAt 调用（String.java:1675-1682），每处都属于第②/③/④层——callee charAt 声明为 @FastNative native，但也是 kStringCharAt intrinsic；若 boot image 为它生成了 AOT intrinsic 方法体，quick code 就是这段编译方法体（count/bounds/字节加载，普通 quick 帧），不是 GenericJNI；只有在没有 AOT intrinsic 代码时，image_writer.cc:3530-3534 才回退 GenericJNI，建立 JNI 帧并压 LRT（FastNative 只跳过状态转换与 artJniMethodStart，不跳过 LRT）。nterp 先按 managed ABI 把 receiver (String*) 与 index 放到 quick code 参数位置（A0=ArtMethod*、实参从 A1）；若落到 GenericJNI，后者再按 JNI 约定把它转成 JNIEnv*、jobject/jclass 与 native 参数。返回后再把结果放回 dex 寄存器（char 为 32 位整数，走 a0）。两个 ABI 段不能合并成“寄存器布局恰好一致”，也不能把“可能走 GenericJNI”写成“必然走 GenericJNI” [S17][S19][S20][S43]。

4.3.5 异常、挂起与热度

• 异常落地：nterp 所有异常共用一个 landing pad——NterpGetCatchHandler() 返回 artNterpAsmInstructionEnd（nterp_helpers.cc:223-227）；在 longjmp 前运行时会写好 dex_pc_ptr，落地后据此决定跳转的 catch handler。nterp_deliver_pending_exception（main.S:674 区段）以 DELIVER_PENDING_EXCEPTION 完成统一分派。异常帧的引用/寄存器数组由上面的双数组协议提供，QuickExceptionHandler 可据此还原 [S19][S40]。
• 挂起检查：方法入口与回边都插 DO_SUSPEND_CHECK（main.S 的热度宏内），读 THREAD_FLAGS_OFFSET(xSELF) 的 suspend/checkpoint 位后调 art_quick_test_suspend。riscv64 没有隐式挂起检查（CanUseImplicitSuspendCheck() 为 false，arm64 可隐式化），因此每次安全点都是显式的 load+branch [S11][S19]。
• 热度与 OSR：START_EXECUTING_INSTRUCTIONS 与 NterpHotnessCheck 在计数器归零时调用 nterp_hot_method（NterpHotMethod）；对回边，C++ 侧准备 OsrData，返回非空时 nterp 自己丢弃当前帧、保持 callee-saves 与 OSR 帧一致、把 OsrData 的 spill 区倒序拷贝到新栈、free 后 jr 到编译代码（main.S:610-634）。注释明确“nterp 的 callee-saves 与 OSR 帧一致”是这条快速迁栈的前提 [S19][S18]。

4.3.6 失败与回退

• nterp 不可用：debuggable、-Xint、entry/exit stubs、JIT 首用编译等条件满足 CanRuntimeUseNterp() == false → 所有方法回退 switch 解释器；-Xint 由 Runtime::Init 的 Opt::Interpret 触发 ForceInterpretOnly()（runtime.cc:1831-1833）[S05][S18]。
• 方法级不可用：native、代理、MustCountLocks、帧过大 → 该方法的入口不是 nterp（native 若无 AOT intrinsic 代码则走 GenericJNI；代理走代理入口；普通 Java 方法若帧过大则不能用 nterp，按其入口状态执行）[S40]。
• 未实现 opcode 的历史坑：2023 年 riscv64 的 nterp 曾是 unimp 桩，2023-06 起以“方法过滤器（排除 try 块/未实现 opcode）”方式启用，2024-01 补齐异常捕获后进一步放开（过滤器退场的精确节点未逐一核）；今天这段历史仍是“目录存在≠可执行”的最好反例 [S33]。
• 可复现观察（未执行）：logcat 中解释器相关日志、kill -3 查看解释器帧的 dex pc、run-test --interp 用例集；设备前提与版本一致。

4.3.7 小结：解释器的可复述模型

对一次未编译的 String.equals：入口 → nterp 序言（快路径或短慢路径）→ 循环 opcode（iget/invoke-virtual/if-*）→ charAt 的 invoke 按四层规则离开 nterp，落到 AOT intrinsic 方法体或 GenericJNI 回退 → 返回后继续循环 → 计数归零触发 NterpHotMethod，可能 OSR 进 JIT。下一章回答：编译侧如何把同一个循环变成 RV64 的内联比较。

第 4 章（4.4）从 profile 到机器码：JIT/AOT 编译流水线

本章回答：String.equals 这段代码“什么时候、被谁、用什么规则”编译；同一个方法在不同构建/运行模式下的入口为何不同；IR、寄存器分配、stack map 与去优化如何串起来。行号均以 ART android17-release b753cf97 为准；阈值只按 pin 与条件陈述，不把默认值当设备实际值。

4.4.1 两条编译入口与编译过滤器

ART 有两条编译路径，共用优化编译器的后半段：

• AOT（dex2oat）：dex2oat/dex2oat.cc:3248 main → Dex2oat()（:3157）→ ParseArgs→Setup（:1496）→ DoCompilation（:3109）→ Compile()（:1889）→ CompilerDriver（构造 :1952）→ PreCompile（dex2oat/driver/compiler_driver.cc:861）→ CompileAll（:314）→ 单方法 CompileMethodQuick（:430）。产物写入 oat/vdex/image（4.2）。
• JIT（运行期）：runtime/jit/。Jit::MaybeEnqueueCompilation（jit.cc:1747）决定任务类型，编译线程池只有 1 个 worker（jit.cc:1135），任务队列优先级为 generic→OSR→fast→baseline→optimized；JitCodeCache 上限 64 MB（jit_code_cache.h:185），分为 zygote 共享区与进程私有区（ProfilingInfo 只能放私有区）。

编译过滤器（libartbase/base/compiler_filter.h:34 起，8 档：kAssumeVerified/kVerify/kSpaceProfile/kSpace/kSpeedProfile/kSpeed/kEverythingProfile/kEverything）决定 AOT 覆盖范围：默认 kSpeed；dex2oat 检测到 profile 时把 kSpeed 升为 kSpeedProfile（dex2oat.cc:1217-1222）；超大应用降级 kVerify（:129-130、:1562-1575）。设备侧主镜像的过滤器来自 odrefresh：a17r 中主镜像与 mainline 扩展的默认值都是 speed-profile（odrefresh/odrefresh.cc:130、:133；无 profile 时回退 verify）。过滤器名 quicken 只保留兼容：解析时告警并映射为 kVerify（compiler_filter.cc:181-184）——与 4.2 的“VDEX 无 quickening”一致 [S32][S36]。

4.4.2 热度、tiering 与执行路径

层级与回退关系见图 5。读图要点：解释器用方法入口/回边热度与解析慢路径累积信号；触发后进入 1 个 worker 的 JIT 队列，任务类型由“能否分配 ProfilingInfo/是否 native”决定；运行中的去优化会把执行按 stack map 拉回解释器。

图 5： 编译分层与回退（来源：ART a17r 的 jit.cc/jit_options.cc/quick_exception_handler.cc，[S28][S29][S38]，本项目绘制）。-Xint 强制解释；debuggable 禁 nterp/AOT Java 但 JIT 仍可用，二者不能混成一行。

阈值：ART 内的 JIT 默认阈值是 kJitDefaultWarmupThreshold = 0xffff、kJitDefaultOptimizeThreshold = 0xffff（runtime/jit/jit_options.cc:34、:27）；设备实际值由框架属性下发（AndroidRuntime.cpp:897 把 dalvik.vm.usejit 映射为 -Xusejit:、:900 把 dalvik.vm.jitthreshold 映射为 -Xjitthreshold:；warmup 阈值的属性映射不在此文件，按“由框架/配置层决定”处理，不臆测具体数值）。-Xjitosrthreshold 已列入忽略参数（runtime/parsed_options.cc:514）——OSR 没有独立阈值。

触发入口：nterp 的方法入口与回边递减方法计数器（4.3.5）；缓存 miss 的解析慢路径通过 UpdateHotness 加 0xf；计数器归零进 NterpHotMethod（nterp.cc:995 起）→ Jit::MaybeEnqueueCompilation。编译任务类型的决策原文（jit.cc:1819-1824）：

if (!method->IsNative() && GetCodeCache()->CanAllocateProfilingInfo()) {
  AddCompileTask(self, method,
                 UseFastCompiler() ? CompilationKind::kFast : CompilationKind::kBaseline);
} else {
  AddCompileTask(self, method, CompilationKind::kOptimized);
}

也就是说：能分配 ProfilingInfo 的普通方法先进 baseline（arm64 且满足条件时是 fast），否则直接 optimized；fast 失败会回退 baseline。对 riscv64：TryPatternMatch（jit.cc:138-153）服务 arm/arm64，SupportsFastCompiler（jit.cc:1262-1266）仅 arm64；riscv64 只能走 baseline→optimized 的通用阶梯 [S28][S38]。

AOT/JIT/解释三态的选择：镜像加载后方法入口可能是 AOT quick code、nterp 入口或 quick-to-interpreter bridge（4.2.2）；JIT 编译完成由 Instrumentation::UpdateMethodsCode 替换入口。-Xint（InterpretOnly）强制 Java 方法走 switch 解释器并停用 nterp；debuggable 使 nterp 与 AOT Java 代码不可用、fast tier 被拒，但 JIT 仍可生成带 entry/exit hooks 的优化代码（instrumentation.cc:232-238；optimizing_compiler.cc:1440-1474 只拒 debuggable 的 fast tier，CriticalNative 特例在 :1352-1365；AOT 在 debuggable 下仅 native 方法可用，instrumentation.cc:331-335）。因此“同一个 String.equals”的入口要看构建过滤器、运行属性、-Xint/-Xusejit 与 debuggable/instrumentation 状态，不能只用 debuggable 一位推断“必定解释” [S28][S38]。

4.4.3 IR：从 DEX 到 HGraph

优化编译器入口 OptimizingCompiler::TryCompile（compiler/optimizing/optimizing_compiler.cc:782）：HGraphBuilder::BuildGraph（builder.cc:90）把 DEX 字节码降为 SSA 形式的 HGraph；关键 HInstruction 与案例相关的是：

• HInvoke*（虚/静态/接口调用，带 intrinsic 信息）；
• HArrayGet/HArrayLength/HBoundsCheck——String.charAt 的内建把 String 当作数组：kStringCharAt 在 builder 阶段生成 HArrayGet(kUint16, is_string_char_at=true, SideEffects::None) + HArrayLength(is_string_length) + HBoundsCheck(is_string_char_at)（instruction_builder.cc:2125、:2225-2241；简化器版本在 instruction_simplifier.cc:2859-2881），长度读取直接映射到 String::CountOffset()（code_generator.cc:233-236）；
• HDeoptimize（编译期插入的去优化点，例如 CHA/边界检查保护失败）；
• HNullCheck/HInstanceOf/HLoadClass（String.equals 内建的 null/类型分支对应物）。

调用点内建：String.equals 调用在 HIR 层被识别为 Intrinsics::kStringEquals（runtime/intrinsics_list.h:214，签名精确匹配），编译器把整个调用替换为前面的 KV 序列（4.1.4），即使不内联方法体。反过来，String.equals 方法体自身被编译时有两种可能：若非 native Compile 对 method->IsIntrinsic() 走 TryCompileIntrinsic() 并生成整方法 intrinsic body（optimizing_compiler.cc:1142-1154、:1079-1084；intrinsics_riscv64.cc:1141-1149），则不执行 Java 循环；只有走普通 DEX graph 编译时，其循环内的 charAt 调用才被替换为上面的 HArrayGet 路径（instruction_builder.cc:2125）。两种“内建”作用在不同调用点上，这是读 IR 时最容易混淆的一处；具体 boot image 是否生成整方法 body 未实测。

4.4.4 优化 passes 与寄存器分配

RunOptimizations（optimizing_compiler.cc:620，内置序列 :644-716）按阶段运行：常量折叠、InstructionSimplifier、DeadCodeElimination；Inliner（其后 $after_inlining 组）；GVN、控制流简化；不变量外推、归纳变量、BoundsCheckElimination、循环优化；LoadStoreElimination、CHA guard、EnvironmentInputElimination、CodeSinking；最后是 codegen 前清理。arch 专属 pass 单独挂载：riscv64 为 InstructionSimplifierRiscv64、GVN$after_arch、CriticalNativeAbiFixupRiscv64（同文件 :539 附近）[S31]。

对案例的两个机制点：其一，String.equals 的 8 字节循环是否被向量化与本 pin 无关——riscv64 的向量指令 codegen 尚未实现（4.5），因此只能走标量整字比较；其二，只有走普通 DEX graph 编译、String.equals 方法体中的 charAt 循环存在时，HBoundsCheck 能否被 BCE 消除才取决于归纳变量分析能否证明 i < length()；若走整方法 intrinsic body，则不进入该循环；length() 内建读 count 字段，循环上界与数组长度同源，这是 BCE 可能成功的结构基础（是否成功由具体图决定，本文不给未经反汇编的断言）。

寄存器分配只有线性扫描一种实现（register_allocator_linear_scan.cc：AllocateRegisters :393，活跃集满时 TryAllocateFreeReg :1238/AllocateBlockedReg :1470）；Location 抽象负责把 HIR 值放到寄存器/栈/常量位。codegen 前 WriteBarrierElimination 与 AllocateRegisters 的顺序见 optimizing_compiler.cc:943-981 [S31]。

4.4.5 stack map、dex pc 与 CFI

编译产物的栈映射在 StackMapStream 中生成：BeginMethod（stack_map_stream.cc:49）→ BeginStackMapEntry/AddDexRegisterEntry → EndMethod（:84）→ Encode（:382），CreateDexRegisterMap（:318）做寄存器映射的差异压缩。运行期读取侧是 runtime/oat/stack_map.h 的 CodeInfo：按 native pc 取栈映射（GetStackMapForNativePcOffset）、按 dex pc 取（GetStackMapForDexPc），并给出寄存器/栈位与 dex 寄存器的对应。异常展开与去优化都消费这份数据（4.4.6）[S29][S31]。

nterp 帧的“dex pc”不走 stack map，而是帧内保存的 saved dex pc 槽（4.3.2）+ CFI 描述；这解释了为什么去优化时 nterp 帧可以直接拷贝（HandleNterpDeoptimization，quick_exception_handler.cc:583），而已编译帧必须按 stack map 重建（HandleOptimizingDeoptimization，:612，其中 :619 取栈映射）[S29][S40]。

4.4.6 OSR 与去优化

• OSR（栈上替换）：nterp 回边由 NterpHotMethod 触发，Jit::PrepareForOsr 用 CodeInfo::GetOsrStackMapForDexPc 找到 OSR 入口并把解释器 vreg 写入 OsrData，随后 nterp 自己按 OsrData 拷贝栈并跳到 native pc（4.3.5，main.S:610-634）；switch 解释器路径则调用 art_quick_osr_stub（riscv64 实现存在于 quick_entrypoints_riscv64.S:946 起）。
• 去优化：编译代码命中去优化点 → art_quick_deoptimize_from_compiled_code（riscv64 汇编 :716-722）→ artDeoptimizeFromCompiledCode；Thread::Deoptimize → QuickExceptionHandler::DeoptimizeStack/DeoptimizeSingleFrame → DeoptimizeStackVisitor 逐帧重建解释器帧。nterp 帧直接拷贝双数组；optimized 帧按 stack map 的 GetRegisterMaskOf/GetStackMaskOf/GetDexRegisterMapOf 写回 ShadowFrame。instrumentation（debugger 挂起/方法 tracing）可强制整栈去优化（Instrumentation::Deoptimize(*)）。不要把它写成“debuggable 根本不生成机器码”：debuggable 下 JIT 仍可生成带 entry/exit hooks 的代码；真正强制解释的是 -Xint/InterpretOnly，且 CriticalNative 在 debuggable 下是 JIT 的明确例外（optimizing_compiler.cc:1352-1365、:1457-1474）[S29][S38]。

4.4.7 同一用例为什么“模式不同性能不同”

把案例放进不同模式，入口与执行体可以完全确定地推导出来：

这张表也说明：不能用“某个方法是不是 boot classpath 类”推断它的执行体，必须看过滤器、profile、-Xint/-Xusejit、debuggable/instrumentation 与入口点状态；debuggable 不是“禁止所有机器码”的同义词。本文不给任何耗时数字；表中的“慢/快”只是相对路径描述，真实差异需设备测量（观测口径见 4.10）。

4.4.8 失败、回退与观察

• JIT 失败：fast→baseline 回退（JitCompileTask 内，jit.cc:709-721）；baseline/optimized 编译失败不改变方法入口（仍解释执行）。
• 去优化回退：CHA 失配、inline cache 失配、BCE 保护失败等会按 stack map 回到解释器（4.4.6）；这是“跑一会儿变慢/变快”的常见来源。
• AOT 缺失：过滤器为 verify/无 profile 覆盖时无 AOT 代码，全靠 nterp+JIT。
• 可复现观察（未执行）：-verbose:jit 看编译入队/完成、oatdump 看 AOT 代码、profman --dump-info-for 看 profile 是否覆盖、-Xjitshutdown-dump 类开关在停进程时打印 JIT 统计；设备与同版本工具是前提 [S37]。

成本与权衡：AOT 把编译成本前移到安装/开机窗口，换稳态执行；JIT 按热度分摊，换来代码缓存与运行时编译开销；OSR 缩短长循环等待，但要求回边有 OSR stack map；去优化保证正确性，代价是回到解释器并可能再次编译。选择由过滤器、profile 与热度共同决定，不是单一“优化等级” [S28][S31][S36]。

下一章进入 RV64 后端：同一份 HIR 在 riscv64 上如何变成寄存器分配后的 LIR、如何为 String.equals/charAt 选指令，以及 ABI/内联数据/RVV 的边界。

第 5 章（4.5）RISC-V64 后端：ABI、指令选择、内建与扩展边界

本章回答：同一份 HIR 到 riscv64 机器码之间隔着哪些层；ART 私有 managed ABI 与 RISC-V psABI 在哪里分界；String.equals/charAt、System.arraycopy 在 RV64 上被选成什么指令序列；ISA 扩展（C/Zba/Zbb/Zbs/V）是怎么被发现和消费的；哪些“能力”只是汇编器存在而不是 codegen 可用。行号以 ART android17-release b753cf97 为准；未反汇编、未运行设备。

4.5.1 后端分层与 ISA 特性的真实来源

RV64 后端由四层构成：汇编器（compiler/utils/riscv64/assembler_riscv64.{h,cc}，约 2900+7900 行，负责编码、伪指令、压缩指令与扩展掩码）、指令选择/codegen（compiler/optimizing/code_generator_riscv64.cc）、内建（intrinsics_riscv64.cc）与运行时入口汇编（runtime/arch/riscv64/quick_entrypoints_riscv64.S）。此外还有 managed_register_riscv64、instruction_simplifier_riscv64、critical_native_abi_fixup_riscv64、relative_patcher_riscv64、disassembler_riscv64 [S10][S11][S12][S34]。

ISA 特性探测（关键事实）：riscv64 的特性对象在 ART 里没有运行期探测。Riscv64InstructionSetFeatures::FromCpuInfo/FromHwcap/FromAssembly/FromCpuFeatures 全部是 UNIMPLEMENTED(WARNING)，然后回退到 FromCppDefines()；后者只看编译期宏（__riscv_c/__riscv_v/__riscv_zba/__riscv_zbb/__riscv_zbs，加总是 kExtGeneric）。FromVariant 只接受 "generic"；唯一的运行期输入是 AddFeaturesFromSplitString 解析显式 ISA 字符串（供交叉/镜像指令集声明等场景）（runtime/arch/riscv64/instruction_set_features_riscv64.cc:40-145）[S34]。这意味着目标二进制在编译时假定哪些扩展，运行时不会再去核对；与 ARM 的 HWCAP 探测模型不同。特性的消费者是可核对的：汇编器用 HasCompressed/HasZba/HasZbb/HasZbs/HasVector 组合扩展掩码（assembler_riscv64.h:1909-1923），codegen 用 HasCompressed 决定代码对齐粒度（code_generator_riscv64.cc:810），Zba/Zbb 路径带 DCHECK（:5537、:5651）[S34][S11]。

4.5.2 ABI 与栈帧：managed ABI ≠ psABI

RV64 的寄存器分工、帧尺寸与 psABI 差异见图 6。读图要点：托管 ABI 用 a0 固定携带 ArtMethod、s1 固定携带 Thread*；托管 ABI 的浮点实参使用 FA0-FA7，超过 8 个直接上栈，不借用整数实参寄存器。psABI 的规则不同：FA0-FA7 用尽后，浮点参数进入 A0-A7，再上栈；这两段在 JNI/GenericJNI 边界衔接，不能把“托管 ABI 不借 GPR”误读成“托管 ABI 不用浮点寄存器”。

图 6： RV64 的 managed quick ABI 与 JNI native ABI（来源：ART a17r 的 registers_riscv64.h/asm_support_riscv64.h/jni_frame_riscv64.h/critical_native_abi_fixup_riscv64.cc，[S10][S30]，本项目绘制）。GenericJNI 在两段之间转换 A0/A1 与 jobject；CriticalNative fixup 只处理超出 FP 寄存器、进入整数寄存器的那部分实参。

托管调用约定（riscv64 私有）：A0 = ArtMethod*（code_generator_riscv64.h 的 kArtMethodRegister = A0），实参从 A1 开始，浮点参数用 FA0-FA7；xSELF=s1 始终携带 Thread*；GP(x3) 被征用为影子调用栈指针（SCS）；TMP=t6、TMP2=t5 保留给汇编宏；TP(x4) 是 bionic 的 TLS 指针，不是 ART Thread（runtime/arch/riscv64/registers_riscv64.h:26-70）。帧尺寸常量（asm_support_riscv64.h:23-56）：FRAME_SIZE_SAVE_REFS_ONLY=112、SAVE_ARGS_ONLY=128、SAVE_ALL_CALLEE_SAVES=208、SAVE_REFS_AND_ARGS=224、SAVE_EVERYTHING=480，nterp 帧 NTERP_SIZE_SAVE_CALLEE_SAVES=192；注释明确列出每个帧排除/包含的寄存器（例如 SAVE_REFS_AND_ARGS 排除 A0 与 TR）。

调用桩：art_quick_invoke_stub（quick_entrypoints_riscv64.S:266）用 INVOKE_STUB_CREATE_FRAME（:23-90 区段）建立 48 字节骨架帧：保存 RA/FP/xSELF/A4/A5，把 A0=ArtMethod*、A1=args ptr、A2=args len、A3=thread 规整后 mv xSELF, a3，再按 16 字节对齐复制参数、最后 ld t0, ART_METHOD_QUICK_CODE_OFFSET_64(a0); jalr t0。返回时恢复帧并处理返回值 [S09][S10]。

与 psABI 的分界：native 调用遵循 RISC-V psABI，浮点参数在 FA0-FA7 用尽后可进入 A0-A7，再上栈；托管 ABI 不做这种 GPR 借用：runtime/arch/riscv64/jni_frame_riscv64.h:35-52 的注释说的是“超过 8 个 FP 实参时不把它们放进整数寄存器，而是直接上栈，以避免编译器复杂度”，同一段仍明确托管 ABI 使用 FA0-FA7，且 kMaxFloatOrDoubleArgumentRegisters=8。因此不能把这句话单摘成“managed 不用浮点寄存器”。@CriticalNative 直呼时，编译期 CriticalNativeAbiFixupRiscv64 只为超过 FA0-FA7、按 native 布局必须占用整数寄存器的那部分 FP 实参插入 Float.floatToRawIntBits/Double.doubleToRawLongBits 型转换；前 8 个 FP 实参仍走 FP 寄存器，并非所有 FP 参数都转整型（critical_native_abi_fixup_riscv64.cc:27-54）[S30]。

4.5.3 指令选择案例：String.equals 与 charAt

当调用点被内建时（轴 1 为“是”，见 4.1.4），RV64 的内建序列（intrinsics_riscv64.cc:1152-1240）落实为：参数空检查（Beqz）→ 引用相等（Beq）→ klass_ 比较（两次 Loadwu，无读屏障，依赖 String 类对象不可移动）→ count 比较（Loadwu，同时比较长度与压缩标志；依赖构造规范化，见 4.1.4）→ 压缩标志/字符数换算（Andi/Srliw/Sllw）→ value_offset 起 8 字节 Ld 循环（压缩按 8 字节/轮，非压缩按 4 字符/轮）→ 返回 0/1。value_offset 是 String 对象内联数据区（4.2.3），因此这里没有任何“取数组引用+读屏障”的步骤 [S12][S16]。

charAt 内建（HArrayGet(is_string_char_at)）在 RV64 的实现（code_generator_riscv64.cc:2876-2905）：读 String::CountOffset() 的 count → Andi 0x1 判压缩 → 压缩时 Loadbu 取单字节；非压缩走 16 位加载；越界慢路径按 HBoundsCheck::IsStringCharAt() 选 kQuickThrowStringBounds（而不是数组越界入口，:396-401），抛出 StringIndexOutOfBoundsException。这与案例解释路径的 mirror::String::CharAt（C++）语义对齐：两者都从同一 count 布局出发 [S11][S16][S17]。

与 ARM64 的可核对差异：arm64 的 VisitStringEquals（intrinsics_arm64.cc:2539 起）在常规 8 字节循环之外还有一个 const-string 特化：当调用点一侧是编译期常量字符串且长度不超过阈值时，直接用 Ldp 成对加载与常量比较，并先用常量长度生成 GetFlaggedCount 与参数 count 比较；riscv64 的 intrinsics_riscv64.cc 中没有 GetConstString/DexFileStringAllASCII/GetFlaggedCount 的对应路径（检索为空）。这是一处真实的 RV64 内建缺口，而不是“指令更强/更弱”的判断——两条路径的正确性相同，差异只在编译期可做的特化数量 [S12][S34]（arm64 对照实现：intrinsics_arm64.cc:2539 起）。

4.5.4 原子与内存序的 RV64 形态

• volatile 写：StoreSeqCst（code_generator_riscv64.cc:1033-1074）对 ≥4 字节类型用 AMOSWAP.D/W（AqRl::kRelease）丢弃返回值充当顺序一致的 store（这是源码的当前实现；该组合是否满足 JMM 对 volatile 写的 SC 要求，源码未给论证，列为待查，见 4.7.5）；<4 字节用 fence+store+fence 组合。
• volatile 读：读前 GenerateMemoryBarrier(kAnyAny)、读后 kLoadAny（HandleFieldGet 路径）。
• 屏障映射：GenerateMemoryBarrier（:6232-6246）把 kAnyAny/kAnyStore/kLoadAny/kStoreStore 映射到 fence rw,rw / rw,w / r,rw / w,w。
• CAS：GenerateCompareAndSet 用 LrW/ScW（32 位）或 LrD/ScD（64 位）组成“LR→比较→SC→失败重试”循环；强 CAS 必须重试，弱 CAS 只尝试一次并把 SC 结果取反（intrinsics_riscv64.cc:1276、:1298-1314）。本 pin 没有 Zacas 类单指令 CAS。
• AMO get-and-update：完整字宽的 set/add/and/or/xor 直接用 AMOSWAP/AMOADD/AMOAND/AMOOR/AMOXOR（GenerateGetAndUpdate，:2256-2348）；只有 32 位且带 mask 的 set/add 需要“读-改-写”部分位，使用 LR/SC 循环（:2280-2293、:2302-2322）。因此“原子读改写一律 LR/SC”不成立。
• 锁：LOCK_OBJECT_FAST_PATH（asm_support_riscv64.S:804-839）用 lr.w.aq/sc.w 实现 thin lock；解锁用 lr.w + sc.w.rl。宏内 16 条指令的限制是 ART 为受约束 LR/SC 序列获得前向进展保证而维护的序列约束（同时受 ScopedLrScExtensionsRestriction 只允许 Zca 等约束），不是“所有 LR/SC 指令合法性的普遍硬上限”。

这条组合的语义边界是：RVWMO 下 fence 组合提供所需的获取/释放与顺序一致语义；LR/SC 循环在争用下需要重试；AMO 路径避免了 RMW 循环，但并不自动提供比所标注 aq/rl 更强的语义。与 arm64 LSE 的差异是机制差异，不是快慢结论（未测量）[S11][S12][S10]。

4.5.5 内建覆盖与两条热点链

覆盖盘点（按 IntrinsicCodeGenerator<ARCH>::Visit* 去重）：a17r riscv64 170 项，a16q2 176 项，arm64 179 项。arm64 有而 riscv64 无的差集在本次重写中复核为两类：CRC32 系列（CRC32Update/Bytes/ByteBuffer）与 FP16 系列（算术/比较/转换）；此外 4.5.3 的 const-string 特化是代码内特化而非独立 Visit，不计入该项数 [S12][S38]。

• String 链：String.equals（kStringEquals）、charAt（kStringCharAt→HArrayGet）、length/isEmpty（kStringLength/kStringIsEmpty→HArrayLength）、compareTo（kStringCompareTo）、indexOf 家族（kStringIndexOf 等）、StringFactory.newStringFrom* 均有内建入口；libcore 侧的 StringLatin1/StringUTF16.indexOf 是另一套（用于非 String 容器与部分路径），不要与 String 内建混为一谈 [S13][S21][S22]。
• arraycopy 链：System.arraycopy 在 libcore 是 public static native（System.java:448），运行期 native 实现位于 runtime/native/java_lang_System.cc:50 System_arraycopy（另有 System_arraycopyTUnchecked 等类型化快路径）。编译期内建 VisitSystemArrayCopy（intrinsics_riscv64.cc:1723）先做空指针/重叠方向检查（CheckSystemArrayCopyNullOrOverlap）、源/目标越界检查，再做类型系统检查（Class/ComponentType/PrimitiveType/Monitor 字段），对引用数组支持 Baker 读屏障慢路径（DCHECK_IMPLIES(codegen_->EmitReadBarrier(), kUseBakerReadBarrier)），其余情况转 IntrinsicSlowPath 回落 native。同一 System.arraycopy 调用因此有三条路径：内建快路径、内建慢路径→native、以及未编译时的 JNI native——与 String.equals 的两条路径同构 [S12][S17][S35]。

4.5.6 RVV/向量的现状（只写源码可见的事实）

• 汇编器层支持 RVV 指令编码与 CSR（kVlenb 等）与向量 opcode 常量（assembler_riscv64.h:2195-2199），并有 RVV 汇编器测试；
• 编译器层有向量寄存器的基础设施：AllVectorRegisters()、慢路径保存向量寄存器（code_generator_riscv64.cc:127/2627/5358 等），来自上游 “Add vector register allocation, part 1”；
• 但向量 HIR 的指令生成未实现：HasSIMD() 图在 Move 与 Save/RestoreFloatingPointRegister 处 LOG(FATAL)/UNIMPLEMENTED "Vector extension is unsupported"（:6492/:6630/:6640），另有 VTMP 待办注释；HasVector() 在编译器里只出现在汇编器扩展掩码（4.5.1），没有 codegen 消费者；
• 测试构建有一个针对 SBC 的 SIGBUS/ADRALN 变通（libartbase/arch/riscv64/sbc_v_adraln_workaround.cc，宏 ART_TEST_ON_SBC_RISCV64_V_ADRALN_WORKAROUND），注释说明“部分 SBC 几乎符合 RVA22+V，但 V 扩展不满足 Zicclsm，向量非对齐访问触发 SIGBUS”，通过信号处理模拟 vse64.v——仅测试构建，不是产品通路；
• 本 pin 未发现针对 riscv64 的自动向量化路径（loop_optimization 的向量化开启与 arch 相关；RV64 codegen 的向量 FATAL 已足够说明“生成端不可用”）。因此“RVV 已支持”的说法应限定为“汇编器/基础设施 + 测试可用，优化代码生成不可用” [S11][S33]。

4.5.7 失败、回退与观察

• 特性不匹配：因为运行期探测未实现（4.5.1），若二进制按 -march 携带 C/V/Zb* 而目标硬件/内核不提供，执行到对应指令才会暴露（SIGILL 等）；ART 不会在启动时降级特性集。这是“构建期 ISA 假设”的直接风险，需在目标平台构建/部署层控制。
• 不支持的向量图：一旦构造出含 SIMD 的图，codegen 直接 FATAL；正常构建下该路径不可达（没有 RVV HIR 生成器）。
• 内建缺失：CRC32/FP16 等走 libcore 通用实现（不是错误，但路径不同）；const-string 特化缺失只影响编译期可节省的指令。
• 可复现观察（未执行）：disassembler 工具或 oatdump --disassemble 查看方法机器码（需同版本工具）；用 -XX:.../镜像 ISA 字符串核对特性声明；对特性不匹配的复现应在目标硬件上进行（本报告无板卡）。

成本与权衡：内联字符数据让 equals/charAt 的比较只读连续字节，但依赖“字符串不可变 + 零填充”前提；CAS 使用 LR/SC 循环，代价是高争用下的重试；AMO get-and-update 对完整字宽避免循环，但带 mask 的 32 位路径仍要 LR/SC；受约束 LR/SC 的序列长度与前向进展约束影响薄锁快路径的设计；C 压缩指令节省代码体积，代价是汇编器需要更强的约束与分支提升逻辑；RVV 基础设施先行但生成端不可用，当前不能拿来换吞吐。以上都是机制层面的取舍，未做测量 [S11][S12][S34]。

String 的内联字符数据让 equals 的读路径免去字符数组引用的间接加载；klass_ 仍是引用字段（两次 Loadwu），只因 String 类对象不可移动而免读屏障。charAt 越界、分配与引用数组写入仍要与 GC 屏障、TLAB 和 safepoint 打交道。下一章进入 GC/内存。

第 6 章（4.6）GC 与内存：对象、分配、collector、屏障与完整回收链

本章回答：Java 对象长什么样、new 在快慢路径上各做什么、默认 collector 如何被选中、读/写屏障在 RV64 上花在哪里、一次 CC 与一次 CMC 回收怎样从根扫描走到对象移动与页回收、引用/finalizer/OOM 的顺序。行号以 ART android17-release b753cf97 为准；设备默认与实测未运行，文中只写条件与源码。

4.6.1 对象与引用：8 字节头、32 位堆引用、内联字符串数据

mirror::Object 的头部只有两个 32 位槽（共 8 字节）：klass_（HeapReference<Class>）与 monitor_（LockWord 编码：锁状态/哈希/读屏障状态位/CMC 的 mark bit）（runtime/mirror/object.h:75、:807-809；位域见 runtime/lock_word.h:94-140）。Java 堆内的对象引用是 32 位压缩引用（HeapReference 内部 Atomic<uint32_t> reference_，static_assert 校验大小；kHeapReferenceSize = sizeof(uint32_t)，runtime/runtime_globals.h:173、object_reference.h:220-224），因此堆地址空间受 4GB 约束。这里必须限定范围：32 位的是堆引用字段/数组元素/栈上根槽，不是所有指针；JNI jobject、native 指针、ArtMethod*/mirror::Object* 在 64 位进程里仍是 64 位。把“压缩引用”推广成“JNI 句柄或 native 指针也是 32 位”会直接读错边界代码 [S30]。

对象头之外，String 是特例：字符数据内联在对象里（count_、hash_code_、value_/value_compressed_ 联合，runtime/mirror/string.h:316-326；ValueOffset() 即内联数据起点）。因此 String.equals 内建（4.1.4/4.5.3）读的是同一对象的连续字节，不需要“先取数组引用”。但不能据此说“没有引用字段读取”：内建在需要类型检查时会两次 Loadwu 读取 str->klass_/arg->klass_（intrinsics_riscv64.cc:1185-1200），klass_ 是 HeapReference<Class> 引用字段；它之所以不需要读屏障，是因为 AssertNonMovableStringClass() 依赖 String 类对象不可移动。value 内联只说明没有数组引用加载，不能推出所有引用读取都不存在。

4.6.2 分配：TLAB bump 是主路径，慢路径才是 GC

分配统一入口 Heap::AllocObjectWithAllocator（runtime/gc/heap-inl.h:45）。快路径判断：大对象（ShouldAllocLargeObject，:95，判定为 byte_count >= large_object_threshold_ 且是 primitive array 或 String；阈值 kMinLargeObjectThreshold = 12KB，heap.h:160）走 LOS；否则若分配器是 TLAB 型且空间足够，直接 Thread::AllocTlab(bytes)——thread-inl.h:441 只做 ret = thread_local_pos; thread_local_pos += bytes，空间由调用方保证。TLAB 的扩张按 kPartialTlabSize=16KB（heap.h:138）做部分扩张，新 TLAB 从 BumpPointer/RegionSpace 取得；失败才进入 Heap::AllocateInternalWithGc（heap.cc:2002）的等待/GC 循环。

分配失败循环的顺序（heap.cc:2002-2160）：先 WaitForGcToComplete，若已有 GC 完成则重试分配；否则按 next_gc_type_ 跑一次不清软引用的 GC；若回收量/空闲比例仍不够，再跑 gc_plan_.back() 的完整 GC，并把 clear_soft_references 置 true；最多重试 kMaxGcAttempts=5，仍失败才抛 OOM。这个顺序是 4.6.8 软引用语义的基础，不要写成“每次 GC 都清软引用”或“只有 OOM 瞬间才处理软引用”。

注意“纯 bump”并不完整：C++ 快路径在 bump 之后还要 SetClass，Baker 配置下做读屏障状态断言，并执行构造屏障（ThreadFenceForConstructor，heap-inl.h:118-128）；编译代码则由编译器在构造器返回处插入 StoreStore 构造屏障（VisitConstructorFence，code_generator_riscv64.cc:3655-3660），所以“对象引用发布前可见构造结果”是单独的一步，不是 bump 自带的。

RV64 的编译代码路径：TLAB 快路径是手写汇编（ALLOC_OBJECT_TLAB_FAST_PATH_RESOLVED，quick_entrypoints_riscv64.S:1793 起）：读 THREAD_LOCAL_POS_OFFSET(xSELF)、加大小、写回、更新对象头；大数组检查阈值后转慢路径。也就是说，new 在热路径上通常只有“读线程指针 + 加法 + 写回 + 对象头初始化”，没有锁、没有 GC 调用——GC 成本主要来自 TLAB 用尽后的批量记账与并发触发（ShouldConcurrentGCForJava，heap-inl.h:471，按 concurrent_start_bytes_ 或时间触发策略判定）[S30]。

4.6.3 Collector 选择：默认由 uffd 与读屏障共同决定

runtime/gc/collector/ 在 a17r 的集合是：concurrent_copying、mark_compact、mark_sweep、partial_mark_sweep、sticky_mark_sweep、semi_space 等，没有 cms\* 目录——独立 CMS 实现早已删除；仍保留 kCollectorTypeCMS 枚举与 MarkSweep(is_concurrent) 复用形态（collector_type.h、mark_sweep.h:65-73）：CreateGarbageCollectors 在 -Xgc:CMS 且 MayUseCollector(kCollectorTypeCMS) && concurrent 时创建并发 MarkSweep（heap.cc:861-866），但这不是默认路径。构建默认 GC 类型为 ART_DEFAULT_GC_TYPE=CMC（build/art.go:50）；运行期前景 collector 的选择是 gUseReadBarrier ? kCollectorTypeCC : xgc_option.collector_type_（runtime.cc:1914），背景为 CC 后台（:1878 区段）。

CMC 的可用性条件（按源码逐项）：ShouldUseUserfaultfd()（mark_compact.cc:310-325）在 Linux 上返回：显式 -Xgc:CMC（FetchCmdlineGcType 扫 /proc/self/cmdline），或（未显式指定 && Android 目标 && SysPropSaysUffdGc() && 内核支持）。SysPropSaysUffdGc 的完整布尔是 (phenotype_enable || build_enable || is_at_most_u) && !phenotype_force_disable（mark_compact.cc:293-305）：phenotype_enable 读 persist.device_config.runtime_native_boot.enable_uffd_gc_2（默认 false），phenotype_force_disable 读 force_disable_uffd_gc（默认 false），build_enable 读 ro.dalvik.vm.enable_uffd_gc（默认 false），is_at_most_u = !IsAtLeastV() 是 OR 项——Android U 及以下在未 force_disable 且内核支持时默认启用 uffd/CMC，V 及以上才依赖显式属性；此外还有内核能力与构建/运行期 CHECK 门，不能把“U 及以下”单项当成设备必然 CMC；内核侧最低要求 MREMAP_DONTUNMAP + userfaultfd(UFFD_USER_MODE_ONLY) + UFFD_FEATURE_SIGBUS（:130-185）。不满足则 gUseUserfaultfd=false，回落到“读屏障 + CC”组合。构建与运行期还有交叉校验：heap.cc:452-467 要求 uffd 配置必须配 CMC，读屏障配置必须配 CC，否则 CHECK 失败。generational：ShouldUseGenerationalGC()（mark_compact.cc:331；host 恒真，:346）与运行时门控共同决定 minor（sticky）/major（full）策略；CC 的 young 实现与 CMC 的 YoungMarkCompact 都在 collector 目录内 [S30]。

这里不要写“默认 collector=CC”或“默认=CMS”这类绝对句：a17r 的默认是“构建期 CMC + 运行期 uffd/读屏障条件选择”；设备上是否真的用 CMC，要看内核 uffd 能力与属性，本文未在设备验证。

4.6.4 屏障：读屏障的 RV64 形态与写屏障卡表

• Baker 读屏障：对象路径 ReadBarrier::Barrier（read_barrier-inl.h:35-104）先判 IsGray（:49），灰则慢路径 Mark；根路径 BarrierForRoot（:107、:156）用 Thread::GetIsGcMarking() + Mark。riscv64 没有 marking register：编译代码对每个引用寄存器都从 Thread 载入“该寄存器对应的 mark entrypoint 指针”再判空（槽位由 ReadBarrierMarkEntrypointOffset 计算，T5/T6 映射到 0/1 槽；code_generator_riscv64.cc:164-174）（art_quick_read_barrier_mark_regNN，入口宏 READ_BARRIER_MARK_REG 在 quick_entrypoints_riscv64.S；codegen 侧 EmitBakerReadBarierMarkingCheck 与 GenerateFieldLoadWithBakerReadBarrier 在 code_generator_riscv64.cc:1329-1994 区段）。代码内有明确待办注释：“Introduce a marking register…”。当构建启用读屏障时，非 Baker 的读屏障在 riscv64 codegen 未实现（AddReadBarrierSlowPath/GenerateReadBarrierSlow 直接 LOG(FATAL) "Unimplemented"，:1996-2025）——所以“RV64 只支持 Baker”限定在读屏障路径；CMC 的 uffd 路径不使用读屏障，不能被这句话排除 [S11][S19][S30]。
• 写屏障=卡表：WriteBarrier::ForFieldWrite 等直接 CardTable::MarkCard(dst)（write_barrier-inl.h:30-43），没有 SATB 日志；riscv64 的 art_quick_aput_obj 在存引用后按对象地址右移写卡表一字节（quick_entrypoints_riscv64.S 相应区段），属“编译器内联 + 必要时慢路径”的共同结果 [S30]。
• 范围：读屏障只覆盖需要移动/标记的堆引用读取；字符串内联字符、primitive 字段、native 指针不经过它。JNI 边界还要看线程状态（4.6.5/4.8），不能把“某个字段无屏障”推广成“整条 native 边界无屏障”。

4.6.5 根、挂起、checkpoint 与对象移动

GC 安全点由 ThreadList::SuspendAll（thread_list.cc:910）→ SuspendAllInternal（:980）实现：取线程列表与挂起计数锁、对其他线程逐个 IncrementSuspendCount（带 suspend barrier 计数与 immune 机制）、等待被挂起线程到达安全点。GC 主流程 Heap::CollectGarbageInternal 以 kWaitingPerformingGc 状态串行化回收。根集合包含线程栈（quick frame 逐 vreg）、ClassLinker/DexCache/Intern 表等（Runtime::VisitRoots/ClassLinker::VisitRoots/Thread::VisitRoots）。nterp 帧的根扫描走双数组协议：NterpGetReferenceArray（nterp_helpers.cc:196）给出引用影子数组，对象移动时同时改写 regs 与 refs 数组（4.3.2）[S30][S40]。

普通 JNI 与 Fast/Critical 的挂起语义不同：普通 JNI 在进入 native 前转为非 kRunnable（quick_jni_entrypoints.cc:71-72 的 artJniMethodStart 路径），对 GC 而言属于可挂起状态；@FastNative 通常保持 kRunnable，只在返回时 CheckSuspend()（:157-169）；@CriticalNative 不做状态转换也不检查挂起。Thread::IsSuspended() 的判据是“非 Runnable 且有 kSuspendRequest”（thread.h:461-468）。因此“native 长驻导致 GC 常卡住”必须限定：普通 JNI 不会因为“在 native 里不检查 flag”而阻塞 GC；真正可能拖住挂起的是长期运行的 FastNative/CriticalNative 代码、持有 checkpoint 的线程，或 native 重入 Java 时未正确转换/检查的路径。CriticalNative 的“GC disabled”是运行时对这段调用不进行 GC 的协议约束，不等于“全进程任何并发 GC 都停止” [S43]。

checkpoint 的语义（thread_list.h:131-182）：RunCheckpoint 不等待运行中线程完成（:151）；对已挂起线程由调用者代跑。返回本身不是完成门：调用者还须正确等待所有 callback 完成（通常通过 barrier）并观察完成，之后才可用“先前存在的线程执行过一段保持挂起的代码，且调用 happens-before 其结束”的保证（:168-173）。新线程范围按 :161-166，只覆盖先前存在的线程，不扩到所有未来线程。RunEmptyCheckpoint 当前实现明确不保证与 RunCheckpoint 相同的性质（thread_list.h:189-199 的待办注释 b/382722942），不能把它当作等价同步点（4.7.2）。