G1 barrier优化

[lfeng14]

子项	Pair 1	Pair 2	Pair 3	三对中位收益	判断
page-rank	+4.11%	-0.42%	-1.17%	-0.42%	基本持平、波动较大
par-mnemonics	+5.76%	+6.56%	+2.87%	+5.76%	稳定正收益
neo4j-analytics	-0.80%	+0.10%	-3.24%	-0.80%	偏负，不受益
reactors	+1.59%	+0.83%	+3.09%	+1.59%	稳定正收益
四项几何平均	+2.70%	+1.81%	+0.42%	+1.81%	三对均为正

正数表示耗时下降。

结论：这个点值得保留继续推进，主要收益来自 par-mnemonics 和 reactors；但不能说四项都受益，page-rank 接近噪声，neo4j-analytics 有约 0.8% 的中位回退。

实现内容：

• 支持新实例和新对象数组初始化写。
• 仅在对象未发布、无中间 safepoint、写操作不会绕过下一次分配重复执行时消除 barrier。
• 首次字段写可同时消除 pre/post barrier。
• 同字段二次写保留 SATB pre barrier。
• 直接复用 -XX:+/-ReduceInitialCardMarks，没有修改 C3 编译线程并发度。
• 生产 IR 验证中，两次完整 G1 pre/post barrier 已简化为两条字段 store。

验证结果：

• LLVM 定向测试通过。
• JDK release images 构建通过。
• 3 个 GC jtreg 测试通过。
• 四项 Renaissance smoke 全部通过。
• 正式测试 24/24 个 JVM 成功，192 条迭代记录完整。
• 固定 NUMA 2、8 iterations、取 3–7 中位数、三对反序；未使用 CICompilerCount。

实现位于 [InsertGCBarriers.cpp (line 35)](/home/luofeng/jdk21-c3-jit/jeandle-llvm/llvm/lib/Transforms/Jeandle/InsertGCBarriers.cpp:35)，测试见 [reduce-initial-card-marks.ll (line 1)](/home/luofeng/jdk21-c3-jit/jeandle-llvm/llvm/test/Jeandle/reduce-initial-card-marks.ll:1)，完整数据汇总见 [ricm-ab-20260805_1457-summary.md](/home/luofeng/jdk21-c3-jit/results/ricm-ab-20260805_1457-summary.md)。

--- ## 总：它解决什么问题

ReduceInitialCardMarks 的核心目标是：

新对象刚分配出来、字段仍是初始零值时，避免为字段初始化写入生成没有实际作用的 GC pre/post barrier。

C3 原来把所有 Java 堆引用写入都统一处理，即使是构造函数里的初始化写，也会生成完整 G1 barrier：

Node n = new Node();
n.left  = left;
n.right = right;

原来的效果近似：

pre barrier
store left
post barrier

pre barrier
store right
post barrier

优化后，在能够证明安全时变成：

store left
store right

它主要改善对象分配密集、构造函数字段较多的工作负载。实测 par-mnemonics 中位提升约 5.76%，reactors 提升约 1.59%。

分：为什么这些 barrier 可以省

1. 为什么 pre barrier 多余

G1 的 pre barrier 用于 SATB 并发标记：覆盖一个旧引用之前，需要把旧值记录下来，防止正在标记的对象丢失。

但新对象的引用字段在分配后都是零值：

field.oldValue == null

第一次初始化字段时，不存在需要记录的旧引用，因此 pre barrier 没有意义。

不过，如果同一个字段已经写过一次：

n.left = a;
n.left = b;

第二次写会覆盖 a，这时不能再省 pre barrier。因此当前设计是：

第一次写 left：省 pre + post
第二次写 left：保留 pre，只省 post

2. 为什么 post barrier 多余

G1 的 post barrier 主要负责维护 remembered set/card table，例如记录老年代对象指向年轻代对象的引用。

正常 TLAB 分配出来的新对象本身就在年轻代。年轻对象字段初始化不需要记录“老对象指向年轻对象”的关系，因此 post barrier 可以省掉。

但新对象也可能走慢分配，例如：

• TLAB 空间不足
• 大对象或 humongous object
• 非年轻代分配路径

这些情况下不能简单假设对象一定在年轻代。好在 Jeandle 的慢分配路径已经调用了：

SharedRuntime::on_slowpath_allocation_exit(current);

GC 会在这里执行必要的补偿：

• 年轻对象：不需要处理。
• 非年轻对象：使对应区域/card 失效或延迟 card mark。

也就是说，之前 runtime 补偿机制已经存在，只是 C3 编译器还没有据此消除初始化 barrier。

分：编译器如何识别安全的初始化写

实现放在 InsertGCBarriers 阶段。此时：

• 构造函数通常已经内联。
• jeandle.new_instance / jeandle.new_array 还没有被底层分配代码替换。
• 编译器仍能看清“分配对象 → 初始化字段”的关系。

主要分为四步。

第一步：识别新对象来源

从字段 store 的地址反向追踪：

%obj   = call @jeandle.new_instance(...)
%field = getelementptr ..., %obj
store %value, %field

目前支持追踪：

• getelementptr
• bitcast
• addrspacecast
• freeze

最终必须追踪到：

• jeandle.new_instance
• jeandle.new_array

如果经过复杂 PHI、未知指针转换或无法确认来源，就放弃优化。

第二步：确认对象仍然是 fresh object

必须同时满足：

• 分配指令支配字段 store。
• 分配到 store 之间没有可能 safepoint 的调用。
• 对象没有被发布到外部。
• store 不会在没有重新分配对象的情况下循环执行。

例如下面情况不会优化：

Node n = new Node();
possiblySafepoint();
n.left = value;

因为 safepoint 后对象可能已经晋升或被 GC 移动，不能再按“刚分配的年轻对象”处理。

下面也不会优化：

Node n = new Node();
global = n;       // 对象已经发布
n.left = value;

发布后其他线程或未知代码可能访问、修改对象，编译器不再认为字段保持初始状态。

循环重复写也会拒绝：

Node n = new Node();
while (...) {
    n.left = value;
}

第一次可能是初始化，后续迭代已经不是。

第三步：分别判断 pre 和 post barrier

pre 和 post barrier 的条件不同，不能简单一起删除。

对于 post barrier：

对象仍 fresh
→ 可以删除 post barrier

对于 pre barrier：

对象仍 fresh
并且此前没有可能写过同一字段
→ 可以删除 pre barrier

实现会使用 LLVM Alias Analysis 检查此前的字段 store：

n.left = a;
n.right = b;

left 和 right 已证明不别名，两次都属于首次初始化，可以全部省掉。

而：

n.left = a;
n.left = b;

第二次地址可能别名，因此必须保留 pre barrier。

第四步：无法证明就回退

这个实现采用保守策略：

只有明确证明安全才删除 barrier；任何未知情况都维持原有完整 barrier。

会触发回退的情况包括：

• 中间存在函数调用。
• 对象已经逃逸或发布。
• 指针来源无法追踪。
• 复杂 PHI/select 指针。
• 循环可能重复执行同一字段写。
• 未知的原子操作或指针使用。
• 之前存在可能别名的字段写。

所以它不会改变 Java 内存语义，只减少可以确定为冗余的 GC 工作。

开关与流水线设计

没有新增独立 JVM 产品开关，而是直接复用 HotSpot 已有的：

-XX:+ReduceInitialCardMarks
-XX:-ReduceInitialCardMarks

C3 创建 LLVM pipeline 时把这个开关传给 InsertGCBarriers：

HotSpot ReduceInitialCardMarks
              ↓
Jeandle PipelineOptions
              ↓
InsertGCBarriers
              ↓
识别 fresh initializing store
              ↓
决定是否插入 pre/post barrier

这样编译器消除行为和 runtime 慢分配补偿由同一个开关控制：

• 开启：编译器省 barrier，runtime 对特殊慢分配补偿。
• 关闭：编译器插入完整 barrier，runtime 不需要补偿。

这次实现没有修改 CICompilerCount 或任何 C3 编译线程并发度。

总：这个特性的定位

它本质上是一个“新对象初始化写特化”：

• 不是删除所有 GC barrier。
• 只优化明确来自新分配对象的首次字段初始化。
• 利用字段零初始化省 pre barrier。
• 利用年轻代分配和慢路径补偿省 post barrier。
• 通过支配关系、CFG、逃逸检查和别名分析保证安全。
• 证明失败时保持原行为。

当前收益也符合这个定位：

• 对象创建和构造字段写较密集的 par-mnemonics、reactors 收益稳定。
• page-rank 基本持平。
• neo4j-analytics 没有明显受益，存在小幅回退。

因此它是一个有价值但 workload-sensitive 的优化：实现机制成立，正确性边界保守，值得继续保留和完善，但不应宣称所有应用都会提升。

[lfeng14]

C2 的 barrier 优化效果好，核心不是“插得晚”，而是 barrier 从生成开始就是 C2 能理解的 IR，并且和分配、Store、Memory Slice、控制依赖绑定。Jeandle 当前的主要差距是：O3 前插入了不透明函数调用，O3 看不懂 barrier 语义。

C2 怎么做

以 G1 写引用为例，C2 在构建 Store 时通过 BarrierSetC2 同时处理：

pre-barrier
oop store
post-barrier

但会在生成 barrier 前做静态过滤。

1. 新对象初始化时消掉 pre-barrier

G1 pre-barrier 要记录被覆盖的旧值。新对象字段初始为 null，所以只要能证明：

• base 来自同一个 AllocateNode
• 字段 offset 精确
• 从初始化到当前 Store，没有对同一字段的写入或不明内存操作

就直接不生成 pre-barrier。

具体逻辑在 g1BarrierSetC2.cpp，它沿 C2 的 memory chain 反向查找，直到同一对象的 InitializeNode。

2. 新对象初始化时消掉 post-barrier

如果 Store 的目标是刚分配、尚未经过 safepoint 的对象，C2 直接跳过 card mark：

g1BarrierSetC2.cpp

这就是 ReduceInitialCardMarks。慢路径分配可能不在 Eden，因此 runtime 通过 deferred card mark 补偿，当前 Jeandle 的分配 runtime 已经调用了 SharedRuntime::on_slowpath_allocation_exit()，基础设施基本是有的。

3. 运行时 fast-path 层层过滤

无法静态消除时，G1 post-barrier 仍会依次过滤：

• 写入 null：跳过
• source/destination 在同一个 region：跳过
• 目标 card 是 young card：跳过
• card 已经 dirty：跳过
• 否则 dirty card 并加入线程本地队列

代码在 g1BarrierSetC2.cpp。

普通 CardTable 也支持 UseCondCardMark，card 已经 dirty 时避免重复写，减少 cache coherence/false sharing：cardTableBarrierSetC2.cpp。

4. barrier 是特殊 IR，不是不透明 call

例如 card mark 使用 StoreCM，并显式依赖对应 oop Store。这样 C2 可以：

• 精确表达 oop Store → card mark 的顺序
• 区分 Java heap memory 与 raw card-table memory
• 在 Escape Analysis 消掉对象时一起删除 barrier
• 对 arraycopy/clone 使用批量 barrier
• 防止 integerized oop/card address 跨 safepoint

C2 甚至有专门的 barrier 删除入口：cardTableBarrierSetC2.cpp。

Jeandle 当前的问题

现在 InsertGCBarriers 给每个 Java heap oop Store 前后插入两个调用：

call @jeandle.pre_barrier(addr)
store oop
call @jeandle.post_barrier(addr, value)

见 InsertGCBarriers.cpp。

这些调用在 O3 阶段还没 inline，Pipeline.cpp 所说的阻塞主要包括：

• MemorySSA/DSE 不敢跨 call 删除或合并 Store
• LICM、store sinking、loop vectorize 受限
• 地址传给不透明 call，可能影响 capture/escape analysis
• scalar replacement 后 barrier 不容易随 Store 一起消失
• O3 产生的 vector store、memcpy 后又无法补插 barrier

并且 Jeandle 这里已经明确留了两个 TODO：还没有实现 ReduceInitialCardMarks：jeandleRuntimeDefinedJavaOps.cpp。

建议的实现优先级

第一优先级是实现 Jeandle 版 ReduceInitialCardMarks，这通常收益最大：

• 识别 jeandle.new_instance/new_array 返回的新对象
• 用 underlying object + offset 找到 Store 所属对象
• pre-barrier：通过 MemorySSA/AA 证明旧值仍是初始化 null
• post-barrier：证明 allocation 到 Store 之间没有 safepoint/对象发布
• 满足条件时根本不插 barrier

第二步把 barrier call 改成专用 intrinsic/marker，并明确：

• 关联的 oop Store
• base object、derived address、stored value
• 精确 memory effects
• 参数 captures(none)
• 不允许 raw derived address 跨 safepoint

O3 期间保留高层 marker，O3 后再展开为当前 G1 fast-path。单纯给现有 call 加 readonly 或 readnone 不安全，因为 pre-barrier 会读 heap/TLS，post-barrier 会修改 card table 和线程队列。

第三步补充 bulk barrier：

• vector oop store
• llvm.memcpy/memmove
• arraycopy/clone
• 连续 card 范围一次性标记

所以比较合适的方向不是简单把 InsertGCBarriers 挪到 O3 后面，而是：

高层 Store/barrier 语义
    → 新对象与冗余 barrier 消除
    → O3、EA、循环优化
    → bulk/vector barrier 归并
    → RS4GC
    → 最终 barrier lowering

当前最值得先做的是“新分配对象的 pre/post barrier 消除”；这部分能直接复刻 C2 的主要收益，而且不需要先解决完整的 vector/memintrinsic barrier 框架。

[lfeng14]

我给你按 HotSpot/C2 背景 + LLVM实现语义 加中文注释。这个函数的目标是：

判断某个对象初始化阶段的 store 是否可以消除 G1 的 initial card mark（初始写屏障）。

简单理解：

new Object()
    |
    | 初始化字段 store
    |
    v
对象还没逃逸、没有发布
    |
    v
可以省略第一次 card mark

代码：

// 这里只实现 C2 ReduceInitialCardMarks 分析中最保守的一部分。
// 要求：
// 1. 对象分配和初始化 store 必须在同一个基本块(BasicBlock)内。
// 2. 中间不能出现调用(call)。
// 3. 不能出现未知内存写。
// 4. 新对象不能提前被发布(publication)给其他对象。
// 5. 不能存在可能 alias 这个字段的写操作。
// 
// 任何一个条件无法证明安全，都直接放弃优化。
// 后续可以增加更复杂的 CFG 分析和 MemorySSA 分析，
// 但是不能降低当前安全边界。
static bool canElideInitialBarriers(StoreInst *SI, AAResults &AA) {

    // 获取当前 store 写入的地址。
    //
    // 例如：
    // obj->field = value;
    //
    // StoreAddress 就是 field 的地址。
    Value *StoreAddress = SI->getPointerOperand();


    // 找到这个地址最终依赖的底层对象。
    //
    // 例如：
    //
    // %obj = call @allocate()
    // store %value, %obj.field
    //
    // getUnderlyingObject 可以找到：
    //
    // StoreAddress ---> obj
    //
    auto *Allocation = dyn_cast(getUnderlyingObject(StoreAddress));


    // 如果：
    //
    // 1. 没找到对象
    // 2. 不是 Jeandle 创建的新对象
    // 3. 分配和 store 不在同一个基本块
    // 4. 分配指令出现在 store 后面
    //
    // 都无法证明对象处于安全初始化阶段。
    //
    // 因此不能消除 barrier。
    if (!Allocation ||
        !isJeandleAllocation(Allocation) ||
        Allocation->getParent() != SI->getParent() ||
        !Allocation->comesBefore(SI))
        return false;



    // 当前 store 对应的内存位置。
    //
    // 后面通过 Alias Analysis 判断：
    //
    // 前面的写操作是否可能修改同一个位置。
    MemoryLocation StoreLoc = MemoryLocation::get(SI);



    // 检查：
    //
    // allocation 和当前 store 之间有没有危险操作。
    //
    // 这里要求：
    //
    // new Object()
    //     |
    //     |
    //     store field
    //
    // 中间必须非常干净。
    //
    for (Instruction *I = Allocation->getNextNode();
         I != SI;
         I = I->getNextNode()) {



        // Call 需要拒绝。
        //
        // 原因：
        //
        // call 可能：
        //
        // 1. 触发 safepoint
        // 2. 调用 Java 方法
        // 3. 修改堆
        // 4. 发布对象
        //
        // 例如：
        //
        // obj = new Object();
        // foo(obj);        <-- 不知道 foo 干了什么
        // obj.field = x;
        //
        // 不能证明安全。
        //
        // 第一版实现即使知道是 leaf call，
        // 也统一拒绝，保证简单安全。
        if (isa(I))
            return false;



        // 如果是普通 store。
        if (auto *EarlierStore = dyn_cast<StoreInst>(I)) {


            // 获取之前 store 写入的值。
            Value *EarlierValue = EarlierStore->getValueOperand();


            // 判断是否发生对象逃逸(publication)。
            //
            // 例如：
            //
            // new Object()
            //
            // obj.field = newObj;
            //
            // 此时 newObj 被挂到了外部对象上。
            //
            // 其他对象可能马上看到它。
            //
            // 那么后续初始化就不能认为安全。
            //
            if (EarlierValue->getType()->isPointerTy() &&
                getUnderlyingObject(EarlierValue) == Allocation &&

                // 注意：
                // 如果 store 的目标不是自己内部字段，
                // 说明对象被写到了外部位置。
                //
                // 例如：
                //
                // other.obj = newObj;
                //
                // 这是 escape。
                getUnderlyingObject(
                    EarlierStore->getPointerOperand()) != Allocation) {


                // 新创建对象在当前 store 前已经被发布。
                return false;
            }



            // Alias Analysis 判断：
            //
            // 之前这个 store 是否可能修改当前字段。
            //
            // 如果：
            //
            // store A
            // store B
            //
            // 可能写同一块内存：
            //
            // Alias != NoAlias
            //
            // 说明无法证明初始化顺序安全。
            if (AA.alias(StoreLoc,
                         MemoryLocation::get(EarlierStore))
                    != AliasResult::NoAlias)
                return false;


            continue;
        }



        // 对于：
        //
        // atomic store
        // memcpy/memmove
        // memset
        // 未来新增 Java heap write
        //
        // 如果可能写内存，一律保守拒绝。
        //
        // 因为第一版不建立完整 MemorySSA。
        if (I->mayWriteToMemory())
            return false;
    }



    // 所有条件满足：
    //
    // allocation
    //    |
    //    |
    //    store field
    //
    // 中间无调用、无逃逸、无别名写。
    //
    // 可以认为这是对象初始化过程。
    //
    // 因此可以消除 initial card mark。
    return true;
}

---

你可以把这个函数理解成一个非常简化版 C2 ReduceInitialCardMarks：

C2 做：

对象分配
 ↓
Escape Analysis
 ↓
Memory Graph
 ↓
证明第一次写屏障没必要

这个 LLVM 版本做：

对象分配
 ↓
同 BB？
 ↓
中间有 call？
 ↓
有没有逃逸？
 ↓
有没有 alias store？
 ↓
YES → 删除 barrier

所以它不是“发现所有可以优化的情况”，而是：

宁愿漏掉优化，也不要错误删除 GC barrier。

这也是 GC barrier 优化里面非常典型的设计原则。