Renaissance5项劣化分析

[lfeng14]

下面统一按“C2 性能 = 100%，数值越高越好”计算。之前比例由 dev_4 的耗时比取倒数，当前比例采用你在另一环境的实测结果。

总体对比

Renaissance 子项	dev_4 之前性能	当前性能	相对旧 C3 提升	当前 C3/C2 耗时	当前状态
neo4j-analytics	16.8%	32%	1.90x	3.13x	仍严重劣化
page-rank	31.6%	46%	1.46x	2.17x	仍明显劣化
par-mnemonics	31.3%	97%	3.10x	1.03x	基本追平
philosophers	36.1%	116%	3.21x	0.86x	C3 反超约 16%
reactors	60.2%	90%	1.50x	1.11x	接近追平

“当前 C3/C2 耗时”按 100 / 性能比例 换算；例如 32% 表示 C3 耗时约为 C2 的 3.13 倍。

功能变化与残余缺口

子项	当前分支新增、且与该项相关的能力	旧分析中对应的作用	当前仍待补齐	更新后的性能结论
neo4j-analytics	Unsafe _getByte、_getShort、_getLong、_getIntVolatile、_getLongVolatile、_putLongVolatile；Class.isInstance；System.arraycopy	已覆盖旧版 8 个主要 Unsafe 缺口中的 6 个。按旧 profile 计算，大约消掉 21.78 个百分点的可辨认 Unsafe cycles；同时消除部分 JNI/native transition	_getInt、_putByte、_allocateInstance；完整 EA/标量替换；一般代码质量	从 16.8% 提升到 32%，说明补齐的 Unsafe/type/arraycopy 确实有效。但 _getInt 在旧 profile 中单独占约 10.19% cycles，仍是最明确主因
page-rank	Unsafe _getLong、_getShort、_putLong、_getByte、_putInt、_getReference、_getReferenceVolatile；hashCode/identityHashCode；isInstance/isArray/isPrimitive/isAssignableFrom；getLength；arraycopy	旧版 12 个普通 Unsafe 缺口中补了 7 个；hash/type/array 次级组除 allocation 外基本补齐。按旧 profile 约消掉 17.96 个百分点的已知 fallback cycles	_getInt、_putShort、_putByte、_getDouble、_putDouble、_allocateInstance；EA；Spark/TimSort/Kryo 热点代码膨胀和内联边界	从 31.6% 提升到 46%，符合“修了一半显式 fallback、仍剩一半”的静态判断。当前主要问题仍是 Kryo/LZ4 普通 Unsafe 访问
par-mnemonics	arraycopy；Class.isPrimitive；vectorizedHashCode；StringBuilder 构造器 intrinsic；StringBuilder/StringBuffer concat fusion；部分字符串编码 intrinsic	旧 C2 A/B 中，单独禁用 arraycopy 可解释总差距约 29.7%；vectorizedHashCode/isPrimitive 是次要项；concat fusion 有助于短字符串构造	_allocateInstance；完整 EA；部分 stream/lambda 对象消除；一般代码尺寸和内联反馈	从 31.3% 提升到 97%，基本证明 arraycopy 是旧回归的核心开关之一。allocateInstance 虽未实现，但已经不足以造成明显总分回归
philosophers	Class.isInstance；compareAndSetReference；getReferenceVolatile；其他 reference compare-and-exchange/weak-CAS；更多 VarHandle/Unsafe 内存序 lowering	正好覆盖旧版两个最大因果组：isInstance 单项约对应旧总差距 30.6%；reference CAS + volatile load 单项约对应 22.6%。二者在 STM 中会被冲突/重试进一步放大	_allocateInstance；完整 EA；profile devirtualization 的收益模型；并发 STM 下的代码形态和多模态稳定性；primitive getAndAdd direct intrinsic	从 36.1% 提升到 116%，旧版 intrinsic 根因已经基本消失。新结果还表明 intrinsic 补齐改善了事务时序，收益远大于 flat profile 占比
reactors	compareAndSetReference；compareAndExchangeLong；putInt/getIntVolatile/putReferenceVolatile；isInstance/isArray；arraycopy；weak reference CAS	旧版这些 fallback 的可见上限只有约 8%–10% cycles，但它们位于 ForkJoin、队列和消息发送链，修复后可能通过内联及调度反馈产生放大收益	普通 _getInt；_allocateInstance；恢复 direct primitive getAndAdd{Byte,Short,Int,Long}；跨 reactor 调度链代码膨胀；EA/对象消除	从 60.2% 提升到 90%，改善比旧 A/B 预期更大，说明并发调度反馈明显。剩余约 10% 更可能来自 getAndAdd 退化和整体代码形态

当前仍缺失的 intrinsic 汇总

待补功能	影响子项	旧证据/预期影响	优先级
_getInt	neo4j、page-rank、reactors	Neo4j 旧 profile 中 Java wrapper + VM helper 合计约 10.19%；PageRank 约 8.52%	P0
_putByte	neo4j、page-rank	Neo4j 约 2.20%；PageRank 约 1.79%	P0
_putShort	page-rank	PageRank 约 2.20%	P0
_getDouble/_putDouble	page-rank	合计约 0.73%，自身不大，但会影响 Kryo 内联和 transition	P1
_allocateInstance	五项均可能命中，尤其 page-rank/par-mnemonics	旧实验：PageRank 约解释总差距 10.2%；par-mnemonics 约 21.6%；其他项较低	P0/P1
primitive _getAndAdd{Byte,Short,Int,Long} direct intrinsic	reactors 为主，其他并发 workload	dev_4 有、当前分支反而没有；目前会执行 Java volatile-load + weak-CAS 循环	P1
Java heap EA / scalar replacement	page-rank、par-mnemonics、reactors	当前 DoEscapeAnalysis 主要只是内联启发式，没有 C2 ConnectionGraph 对等实现	P1
profile devirtualization 收益模型	philosophers、Scala/actor workload	transformation 本身与旧分支相同，但 intrinsic 补齐后总体结果已改变；需要重新 A/B	P2
通用代码尺寸、内联边界	page-rank、reactors	旧版热点方法存在 1.4–3.3x 代码膨胀；reactors 的消息链仍是主要残余候选	P2

当前分支其他可能产生收益的公共变化

这些功能已经进入当前代码，但无法仅凭现有跨环境数据准确拆分贡献：

• 默认开启 counted-loop safepoint strip mining，chunk 默认 1000：jeandle_globals.hpp。
• 新增 arraycopy lowering 和 specialization：jeandleIntrinsicLowering.cpp。
• 新增 StringBuilder concat fusion：jeandleStringConcat.cpp。
• 补齐 hash、Class query、reference CAS、大量 Unsafe volatile/acquire/release/opaque 操作：jeandleIntrinsicLowering.cpp。
• 增加 fresh-array length folding、CHA/MethodHandle 支持、receiver type 保留和更多循环 canonicalization。
• 当前仍没有已接入 pipeline 的完整 allocation-elimination/escape-analysis pass；现有 DoEscapeAnalysis 使用点仍主要是内联启发式：jeandleCompilation.cpp。

综合看，接下来最划算的实现顺序是：

1. _getInt、_putByte、_putShort。
2. _allocateInstance。
3. _getDouble/_putDouble。
4. 恢复 primitive direct getAndAdd，重点验证 reactors。
5. 再处理 EA、代码尺寸和内联质量。

修完前两批后，Neo4j 和 PageRank 应当是最值得立即重测的两个验收项。

---

初测完成：这 5 项 C3 全部显著慢于 C2，几何平均耗时达到 C2 的 3.08 倍。

Benchmark	C2 末5轮均值 (ms)	C3 末5轮均值 (ms)	C3/C2 (倍)	C3 回退幅度
neo4j-analytics	1,566.8	9,322.6	5.95	+495.0%
page-rank	3,242.0	10,255.9	3.16	+216.3%
par-mnemonics	3,961.1	12,673.0	3.20	+219.9%
philosophers	6,244.4	17,282.2	2.77	+176.8%
reactors	20,388.4	33,879.6	1.66	+66.2%

测试口径：

• BiSheng JDK 21.0.9 release build
• C2：-XX:-TieredCompilation -XX:-UseJeandleCompiler
• C3：-XX:-TieredCompilation -XX:+UseJeandleCompiler
• NUMA node 2
• 每项 10 轮，统计末 5 轮
• 共 100 个 iteration，全部成功，无异常标记
• 末 5 轮 CV 为 0.07%–6.63%，差距远大于运行波动

初步建议：

1. 先分析 par-mnemonics：3.2× 回退且方差最低，最适合做 C2/C3 perf、热点汇编和编译日志对照。
2. 随后分析 neo4j-analytics：回退最严重，达到 5.95×。
3. 再用 page-rank 判断问题是否也集中在 Spark closure、集合和装箱路径。
4. philosophers、reactors 涉及并发和调度，适合在较窄案例确认问题后分析。

详细评估见 [assessment.md](/home/luofeng/jdk21-c3-jit/results/renaissance-c2-c3-selected-20260731_1036/assessment.md)，结构化数据见 [comparison-last-5.tsv](/home/luofeng/jdk21-c3-jit/results/renaissance-c2-c3-selected-20260731_1036/comparison-last-5.tsv)。原始日志：[C2](/home/luofeng/jdk21-c3-jit/results/renaissance-c2-c3-selected-20260731_1036/c2/process.log)、[C3](/home/luofeng/jdk21-c3-jit/results/renaissance-c2-c3-selected-20260731_1036/c3/process.log)。

---

结论：neo4j-analytics 的主要劣化原因是 C3 缺失 Neo4j 高频依赖的 HotSpot intrinsic，尤其是 Unsafe 普通及 volatile 内存访问。结论置信度较高，源码、CPU profile 和因果 A/B 实验三者相互吻合。

实验	稳态时间
C2	1.618 s
C3	9.213 s
C2 禁用 Unsafe intrinsic	5.996 s
C2 禁用全部已识别缺失 intrinsic	6.976 s

在 C2 中主动禁用 C3 缺失的 intrinsic 后，复现了约 70.5% 的 C3/C2 总差距。

C3 当前缺失的关键功能：

• Unsafe 普通/volatile load/store：
  _getInt、_getByte、_getLong、_getShort、_getIntVolatile、_getLongVolatile、_putByte、_putLongVolatile
• _isInstance
• _arraycopy
• _allocateInstance

C3 的 Unsafe 白名单目前基本只有 getAndAdd 和 compareAndSet 原子族，[C3 支持表 (line 163)](/home/luofeng/jdk21-c3-jit/src/hotspot/share/jeandle/jeandleIntrinsicLowering.cpp:163)；而 C2 明确支持完整普通/volatile/acquire/opaque/unaligned 访问族，以及 [`arraycopy` (line 578)](/home/luofeng/jdk21-c3-jit/src/hotspot/share/opto/c2compiler.cpp:578)、[`allocateInstance/isInstance` (line 687)](/home/luofeng/jdk21-c3-jit/src/hotspot/share/opto/c2compiler.cpp:687)。

CPU profile 也直接反映了 fallback：

• ThreadStateTransition::transition_from_native：16.44%
• Unsafe.getInt + Unsafe_GetInt：10.19%
• Unsafe.getByte + Unsafe_GetByte：8.03%
• Unsafe.getLongVolatile + Unsafe_GetLongVolatile：6.10%
• 可识别的 Unsafe wrapper/runtime 合计约 34%

因此 C3 原本应该生成直接 load/store 的位置，实际频繁进入 Unsafe_Get*/Unsafe_Put* VM native 入口，并承担 Java/native 状态切换成本。[C3 原始热点 (line 1)](/home/luofeng/jdk21-c3-jit/results/neo4j-c2-c3-analysis-20260731/c3-profile-v2/perf-report-fields.txt:1)

硬件计数器进一步排除了“缓存劣化”为主因：

• 指令数：C3 是 C2 的 2.71 倍
• IPC：2.52 → 1.59，下降 36.9%
• cycles：4.30 倍
• cache-miss rate：0.944% → 0.802%，反而降低

所以本质是执行了更多 fallback 指令，并且 native 边界降低了流水线效率。

修复优先级建议：

1. 先补齐 Unsafe 普通/volatile load/store lowering。
2. 再补 _isInstance、_arraycopy、_allocateInstance。
3. 修复后检查 Unsafe_Get*、Unsafe_Put* 和 native transition 是否从热点头部消失。
4. 剩余约 29.5% 差距再继续做内联、去虚化和代码尺寸对比；目前证据不足以把这部分归因给某个具体优化。

完整分析、数据和实验说明在[分析报告 (line 8)](/home/luofeng/jdk21-c3-jit/results/neo4j-c2-c3-analysis-20260731/analysis-report.md:8)。初始结果为 C2 1.567 秒、C3 9.323 秒，即 C3 慢 5.95 倍，见[五项对比 (line 19)](/home/luofeng/jdk21-c3-jit/results/renaissance-c2-c3-selected-20260731_1036/assessment.md:19)。

---

par-mnemonics 的主因已定位：C3 缠失 _arraycopy 和 _allocateInstance intrinsic，可以因果解释大约一半劣化。

实验	稳态时间
C2	3.315 s
C3	11.043 s
C2 禁用 _arraycopy	5.607 s
C2 禁用 _allocateInstance	4.984 s
C2 禁用全部已观察缺失 intrinsic	7.278 s

组合实验解释 C3/C2 总差距约 51.3%。

核心证据：

• C3 profile 中 System.arraycopy + JVM_ArrayCopy 占 14.39%，包括数组复制内部路径约 15.55%。
• Unsafe.allocateInstance + Unsafe_AllocateInstance + ObjAllocator 占约 9.77%。
• native 状态切换另外占 8.77%。
• C2 profile 中这些 VM fallback 均未进入热点头部。[C3 热点原始数据 (line 12)](/home/luofeng/jdk21-c3-jit/results/par-mnemonics-c2-c3-analysis-20260731/c3-profile/perf-report.txt:12)

源码也明确证实：

• [C3 intrinsic 白名单 (line 163)](/home/luofeng/jdk21-c3-jit/src/hotspot/share/jeandle/jeandleIntrinsicLowering.cpp:163)没有 _arraycopy、_allocateInstance、_vectorizedHashCode、_isPrimitive。
• C2 支持 [`_vectorizedHashCode` (line 216)](/home/luofeng/jdk21-c3-jit/src/hotspot/share/opto/c2compiler.cpp:216)、[`_arraycopy` (line 578)](/home/luofeng/jdk21-c3-jit/src/hotspot/share/opto/c2compiler.cpp:578)、[`_allocateInstance` (line 687)](/home/luofeng/jdk21-c3-jit/src/hotspot/share/opto/c2compiler.cpp:687)。

剩余约一半表现为代码质量和内联反馈问题：

• C3 指令数是 C2 的 2.40 倍。
• IPC 从 2.69 降到 2.02。
• cache-miss rate 从 0.481% 升到 0.862%。
• HashMap.computeIfAbsent、groupingBy$53、wrapAndCopyInto 等热方法的 C3 机器码约为 C2 的 1.7 倍。
• C2 会把 ArrayList.add → add → grow → grow 整条链内联，[C2 inline 证据 (line 1565)](/home/luofeng/jdk21-c3-jit/results/par-mnemonics-c2-c3-analysis-20260731/c2-inlining/process.log:1565)；C3 因 already compiled into a big method 提前停止，[C3 inline 证据 (line 1520)](/home/luofeng/jdk21-c3-jit/results/par-mnemonics-c2-c3-analysis-20260731/c3-inlining/process.log:1520)。

其他缺口影响较小：

• 缺少 Java heap escape analysis：C2 关闭后劣化约 8.9%。
• 缺少 C2 dedicated StringConcat 优化：约 4.4%。
• _vectorizedHashCode：单独约 2.4%。
• _isPrimitive：基本无影响。

建议修复顺序：

1. _arraycopy
2. _allocateInstance
3. 修复后重新评估代码尺寸和内联反馈
4. _vectorizedHashCode
5. escape analysis 和一般代码生成质量

完整数据和实验记录在[分析报告 (line 8)](/home/luofeng/jdk21-c3-jit/results/par-mnemonics-c2-c3-analysis-20260731/analysis-report.md:8)。

---

page-rank 分析完成。核心结论：C3 是 C2 的 3.163 倍，第一主因是 C3 缺少普通 Unsafe.get/put intrinsic。

关键证据：

• C2 禁用 12 项普通 Unsafe intrinsic 后，可解释 32.7% 的总性能差距。
• 加上 allocateInstance、identity hash、类型检查和 arraycopy 等缺失项，可解释约 56.9%。
• C3 profile 中普通 Unsafe fallback 占 24.05%，native transition 占 14.45%；C2 基本没有这些开销。
• C3 动态指令数为 C2 的 2.846 倍，IPC 下降 15%；cache miss rate 反而更低，排除 cache miss 是主因。
• 剩余约 43% 与内联、代码膨胀和逃逸分析差异有关，目前尚未完全拆分。部分 C3 热点代码尺寸是 C2 的 1.4–3.3 倍。

建议修复顺序：

1. 普通 Unsafe load/store
2. Unsafe.allocateInstance
3. identity hash、arraycopy、类型/数组 intrinsic
4. Spark aggregation/TimSort 内联与代码尺寸
5. 逃逸分析

完整结论、A/B 实验、profile 和源码证据见：analysis-report.md。

---

philosophers 分析完成。初始同批结果 C3/C2 为 2.768x（+176.8%），主要是 intrinsic 缺口被 64 线程 Scala STM 冲突重试放大。

核心结论：

• 最大单项：C3 缺少 _isInstance

  • C3 profile 中 Class.isInstance + jni_IsInstanceOf 占 12.17% cycles。
  • C2 禁用后从 5.829 s 升至 9.211 s，约可解释初始差距的 30.6%。

• 第二主因：缺少 _compareAndSetReference 和 _getReferenceVolatile

  • C3 明确进入 Unsafe/VM fallback，C2 没有。
  • C2 禁用后升至 8.322 s，约对应初始差距的 22.6%。

• C3 profile devirtualization 是额外放大器

  • 三组成对实验平均让 C3 再慢 1.748 s / 11.8%。
  • 但关闭后 C3 仍约 14.9 s，说明它不是全部根因。

• _allocateInstance 是次要缺口，C2 禁用后约慢 8.3%。

• 逃逸分析在本项影响只有约 3%，处于运行波动范围。

• C3 使用的 CPU 核并不少，但受扰动的 PMU 实验中执行了 C2 的 7.43 倍指令、产生 17.73 倍 branch miss，属于额外动态工作和事务反馈，而不是简单并行度不足。

这些比例不能直接相加：组合禁用实验出现非线性结果，证明编译代码形态会改变 STM 冲突、rollback 和 retry 稳态。

建议修复顺序：

1. _isInstance
2. reference CAS 和 volatile reference access 家族
3. _allocateInstance
4. 补齐 intrinsic 后重新约束 profile-devirtualization 的 guard/CFG/code-size 收益模型

完整报告和全部源码、profile、A/B 证据见：analysis-report.md。

---

reactors 分析完成，完整报告见 analysis.md。

核心结论：

• C3 为 33.880 秒，C2 为 20.388 秒，C3 慢 1.662x / 66.2%，绝对增加 13.491 秒。

• 主因是动态指令膨胀：C3 instructions 为 C2 的 2.71x，cycles 为 2.07x；不是单纯 CPU stall。

• 劣化集中在跨 reactor 调度、转发和创建：

  • ForkJoinThroughput：贡献 42.5%
  • Roundabout：16.9%
  • PingPong：12.4%
  • ThreadRing：11.4%
  • ForkJoinCreation：10.2%

  五项合计贡献 93.4%；CountingActor 没有劣化。原始拆分数据见 C2 和 C3。

代码形态上，C3 的 $bang$extension 机器码是 C2 的 2.51x，并占 C3 cycles 的 5.35%；C3 有 37 次因已编译代码过大而拒绝内联，C2 只有 6 次。但调大内联阈值、强制内联 $bang$extension 均没有改善，所以这只是整体代码质量问题的表征，不能归因于单一内联点。

C3 确认缺少本 workload 命中的这些 C2 intrinsic：

• 引用 CAS、compareAndExchangeLong
• Unsafe 普通/volatile 访问
• Class.isInstance/isArray
• arraycopy
• allocateInstance

白名单证据见 jeandleIntrinsicLowering.cpp。它们造成 JNI/runtime fallback，但 profile 上限约 8%–10%，C2 禁用实验也未出现稳定退化，因此是次要项，解释不了 66%。

另外，C3 allocation elimination 目前只是保守子集，而且尚未接入当前编译流水线；对象初始化还使用 atomic store 和临时 release fence。不过 EA、ZeroTLAB A/B 都不支持它们是本次主因。

建议优先以 ForkJoinThroughput 为最小复现，检查：

$bang$extension → send → enqueueEvent → processEvents/executeBatch → ForkJoinPool

重点比较 C2/C3 LLVM IR 和 AArch64 汇编中的重复类型检查、oop/klass load、barrier、CAS/volatile lowering及未消除分支。PMU 原始证据在 C2 perf-stat 和 C3 perf-stat。

[lfeng14]

核验口径：当前 HEAD 2f09455864，使用同一批稳态业务线程 CPU profile。以下比例为 inclusive 或“最深 Java 帧”占比，不能直接等同于性能收益。

1. neo4j-analytics：_allocateInstance 结论可以较强印证

   • C2 的 allocation fallback 链占比为 0%；C3 为 12.60%。
   • C3 中 Unsafe.allocateInstance inclusive 为 12.42%，最深 Java 帧为 12.37%；Unsafe_AllocateInstance 为 9.98%，ObjAllocator::initialize 为 1.89%。这些帧相互嵌套，不能相加，但可以完整证明 C3 正在走 Java wrapper → VM/native → allocator 的 fallback。
   • 调用栈确实分布在 predicate、join/aggregation、cursor 等多条 Neo4j 路径，不是单一方法的偶发热点。
   • 因此，“优先补齐 _allocateInstance”有稳态火焰图和 profile 支持。
   • EA 只能由“C2 关闭 EA 后变慢 5.13%～8.79%”证明 C2 对 EA 敏感；当前 profile 无法证明 C3 实现 EA 后一定获得同等收益。
   • late inline 没有稳定 A/B 收益，火焰图也没有足够证据将其列为主要原因。C3 的 MethodHandle.invokeBasic 为 1.65%，只能作为继续排查的线索。
   • 结论：allocateInstance 为确定项；EA 为候选项；late inline 暂不宜作为 neo4j 的主要结论。

2. page-rank：_allocateInstance 可以印证，EA 和 late inline 需分开表述

   • C2 allocation fallback 为 0%；C3 为 11.98%。
   • C3 Unsafe.allocateInstance inclusive 为 11.93%，最深 Java 帧为 11.84%，比旧报告中的 8.98% 更高，应更新为当前数据。
   • AppendOnlyMap.changeValue 存在明确的编译结果差异：C2 为 INLINED，inclusive 31.20%；C3 为 JIT_COMPILED，inclusive 30.98%。这证明同一个热调用点在 C3 没有内联，但不能仅凭火焰图判断一定是缺少 late-inline queue 导致。
   • C2 关闭 EA 后变慢 16.56%～27.40%，说明 page-rank 对对象优化敏感；但没有 C3 EA on/off 数据，不能把这一区间直接当成 C3 预期收益。
   • C2 late-inline A/B 一组波动较大、另一组基本无变化，当前仍没有稳定收益证据。
   • 结论：allocateInstance 是 P0；EA 是高价值待验证项；AppendOnlyMap.changeValue 是明确的内联候选，但 late inline 的收益需要单点强制内联 A/B。

3. par-mnemonics：_allocateInstance 证据最强，Lambda 只能证明部分热链未贯穿内联

   • C3 allocation fallback 占 27.95%，其中 Unsafe.allocateInstance inclusive/最深 Java 帧均约 27.70%；C2 只有 0.064%。这与原结论中的 28.74% 基本一致。
   • 配合 C2 关闭 _allocateInstance 后变慢约 46% 的 A/B，可以确认它是该子项当前最明确的优化点。
   • EA 的 7%～16% 仍是 C2 敏感区间，不能直接承诺为 C3 收益。
   • C3 profile 中能看到很多 Lambda 已经是 INLINED，说明 invokedynamic/目标恢复并非完全没有实现；但 lambda$wordCode$4 在 C2 为 INLINED、inclusive 12.03%，C3 为 JIT_COMPILED、inclusive 7.96%，证明至少这一条热链没有达到 C2 的贯穿内联效果。
   • ReduceInitialCardMarks 的 2.87%～6.56% 收益来自独立 A/B；Java profile 中几乎没有可直接识别的 barrier 方法，不能用这批火焰图再次证明。
   • 结论：P0 为 allocateInstance；EA 和冗余 barrier 有 A/B 支持；Lambda/Stream 贯穿内联存在具体候选，但不能泛化为“所有 Lambda 都未优化”。

4. philosophers：锁调用链占比差异存在，但“VarHandle/MethodHandle 是主要因素”不能印证

   • 当前稳态数据中，RRWL/AQS inclusive：C2 35.31%，C3 53.11%，可以证明 C3 更多 CPU 样本落在锁调用链之下。
   • 但最深 RRWL/AQS Java 帧只从 C2 的 33.21% 增加到 C3 的 38.19%，直接差异约 5 个百分点。
   • C3 的 park/wait 为 0.89%，低于 C2 的 1.64%；ObjectMonitor 也没有增加。因此不能表述为“C3 锁竞争或锁等待更严重”，更像获取、释放快路径的代码质量或 STM 工作构成不同。
   • VarHandle CAS：C2 2.02%、全部 INLINED；C3 1.16%、全部 JIT_COMPILED。getVolatile 分别只有 0.77% 和 0.63%；C3 MethodHandle.invokeBasic 仅 0.098%。
   • 所以 VarHandle/MethodHandle 的内联差异确实存在，但占比太小，不能认定为主要性能原因。
   • 更值得验证的是 AbstractQueuedSynchronizer.releaseShared：C2 为 INLINED、inclusive 12.46%；C3 为 JIT_COMPILED、inclusive 19.46%。该差异比 MethodHandle 更宽，但仍需强制内联 A/B。
   • C3 allocation fallback 为 1.13%，C2 为 0.02%，可以确认不是当前大头。
   • 结论：原报告中的“VarHandle/MethodHandle 未内联是主要因素”应删除；改为“AQS release 路径和 STM 工作构成存在差异，待做定点 A/B”。allocateInstance 放低优先级。

5. reactors：_allocateInstance 有差异，但“补齐后基本持平”不能由 profile 直接推出

   • C2 allocation fallback 为 0.13%；C3 为 3.18%。C3 Unsafe.allocateInstance 最深 Java 帧为 3.08%。
   • 该占比相对整体 2.21% 的耗时差距值得关注，但 inclusive 比例不是可直接兑现的收益，不能断言补齐后一定完全追平。
   • 当前稳态 profile 与旧 runtime-only 表格有明显差异：
     • Frame.processEvents inclusive 两边接近：C2 34.64%、C3 32.96%；最深 Java 帧则是 C2 6.01%、C3 13.12%。
     • $bang$extension inclusive 也基本一致：C2 19.98%、C3 19.75%；最深 Java 帧只有 0.40% 和 0.54%，不支持旧结论中的 C3 self 5.15%。
     • Frame.openConnector 最深 Java 帧为 C2 0.29%、C3 2.78%，这是可以继续分析的差异。
     • LambdaForm$MH.invoke inclusive 为 C2 20.09%、C3 30.47%，两边均为 JIT_COMPILED，可作为 MethodHandle/Lambda 热链候选。
     • C3 Object.clone 为 0.49%，量级较小。
   • ReduceInitialCardMarks 的约 1.59% 收益只能由已有 A/B 支持，当前 Java profile 无法直接定位机器指令级 card mark。
   • 结论：先验证 allocateInstance；随后看 openConnector、LambdaForm$MH.invoke 和 processEvents 的生成代码。旧的 $bang$extension 大差异不被当前稳态数据支持。

6. 综合判断

   • 稳态火焰图能够较强支持的共同缺口是 _allocateInstance，尤其是 neo4j、page-rank 和 par-mnemonics。
   • EA 的证据来自 C2 关闭实验，说明用例对 EA 敏感，但不能证明 C3 补齐后的实际收益。
   • late inline 只能找到个别“C2 已内联、C3 独立编译”的热调用点，尚不能证明 late-inline queue 是整体差距的主要原因。
   • philosophers 的主要结论应从“MethodHandle 导致锁劣化”调整为“AQS/STM 路径的 CPU 构成和内联结果存在差异”。
   • barrier 优化的收益以已有 A/B 为准，Java 火焰图和函数 profile 不适合直接证明 barrier 消除效果。

[lfeng14]

这个没理解，请举个例子：
P1aastore 类型特化、边界检查合并KVArraySortDataFormat.copyElement 在 C3 为 3.682%，C2 为 1.584%，约 2.32 倍；该方法每次执行包含两个 aaload、两个 aastore和 Type PGO array-store specialization 直接相关

---

可以把 KVArraySortDataFormat.copyElement 理解为一次复制一个“键值对”。它的 Java 逻辑大致是：

void copyElement(Object[] src, int srcPos,
                 Object[] dst, int dstPos) {
    dst[2 * dstPos]     = src[2 * srcPos];      // key
    dst[2 * dstPos + 1] = src[2 * srcPos + 1];  // value
}

对应字节码确实包含：

aaload     // 读取 key
aastore    // 写入 key
aaload     // 读取 value
aastore    // 写入 value

未优化时需要做什么

JVM不能直接相信这些数组访问安全。概念上每个访问都要检查：

// 第一项
checkNotNull(src);
checkIndex(2 * srcPos, src.length);
Object key = src[2 * srcPos];

checkNotNull(dst);
checkIndex(2 * dstPos, dst.length);
checkArrayStoreType(key, dst);       // aastore 类型检查
dst[2 * dstPos] = key;

// 第二项
checkNotNull(src);
checkIndex(2 * srcPos + 1, src.length);
Object value = src[2 * srcPos + 1];

checkNotNull(dst);
checkIndex(2 * dstPos + 1, dst.length);
checkArrayStoreType(value, dst);     // aastore 类型检查
dst[2 * dstPos + 1] = value;

也就是最多包含：

• 4次数组边界检查；
• 2次 aastore 类型检查；
• 2次引用写入；
• 通常还有2次 GC post barrier/card mark。

当前 C3 前端对每个对象数组写入都会生成 array_store_check。jeandleAbstractInterpreter.cpp

Type PGO 怎么优化 aastore

Java泛型擦除后，编译器只看到 Object[] 风格的参数，不一定知道运行时到底是什么数组。Type PGO 可以根据历史执行发现：

dst 运行时几乎始终是 Object[]

而 Object[] 可以保存任意对象，于是生成：

if (dst.getClass() == Object[].class) {
    // 热路径：不再逐个做 array-store 类型检查
    dst[dstBase]     = src[srcBase];
    dst[dstBase + 1] = src[srcBase + 1];
} else {
    // 极少执行的通用慢路径，保留完整类型检查
    genericCopy(...);
}

这就是 array-store specialization：不是改变 Java 语义，而是根据 profile 给常见数组类型建立快速路径。

这个没理解，请举个例子：
P1aastore 类型特化、边界检查合并KVArraySortDataFormat.copyElement 在 C3 为 3.682%，C2 为 1.584%，约 2.32 倍；该方法每次执行包含两个 aaload、两个 aastore和 Type PGO array-store specialization 直接相关

---

边界检查怎么合并

因为总是连续访问两个元素，可以先计算：

int srcBase = 2 * srcPos;
int dstBase = 2 * dstPos;

然后只检查最大下标：

if (srcBase + 1 < src.length &&
    dstBase + 1 < dst.length) {
    // 下面四次数组访问全部安全
}

这样可以把四次独立检查压缩为两次范围检查，并复用 srcBase/dstBase。

当前证据能说明到什么程度

稳态 profile 中：

• C3：copyElement 最深帧占 3.682%
• C2：1.584%
• C3约为C2的 2.32倍

同时，C3 内联树显示该方法在 TimSort 的部分热调用点因为方法体已经过大而没有内联。inline tree

因此更严谨的结论是：

copyElement 是一个已确认的 C3 相对热点；它包含密集的对象数组边界检查、aastore 类型检查和写屏障，Type PGO array-store specialization、边界检查合并及更合理的内联调度都可能改善它。但 3.682% 对 1.584% 尚不能单独证明根因就是 aastore，还需要比较优化后 IR 中实际剩余的 array_store_check、bounds check 和 post barrier 数量，并通过开关该特性的 A/B 跑分确认。