请重新采集 <benchmark> 的 C2/C3 稳态 JIT CPU 火焰图,目标是直观看出 Java 方法的内联差异。
要求:
1. 先跑预采,根据每轮耗时判断预热是否结束;只能在稳态 iteration 开始后 attach,不能包含 JVM 启动和冷编译阶段。若存在快慢多模态,分别采集并明确标记。
2. C2/C3使用相同NUMA节点、JVM参数、采样时长和1ms采样周期。使用:
async-profiler -e cpu -i 1ms -t --cstack vm -F vtable
保存原始JFR和collapsed stack。
3. 识别真实业务工作线程,例如Spark executor、ForkJoin worker或benchmark线程,排除JIT compiler、GC、VM线程。不能只机械地按org.renaissance包名过滤。输出业务样本数量并确认unknown_Java和not_walkable_Java占比。
4. 每侧输出两张图:
a. 标准业务火焰图:<benchmark>-<c2/c3>-standard.svg
b. 保留JIT内联状态的火焰图:<benchmark>-<c2/c3>-inline-state.svg
5. 生成inline-state图时,必须基于async-profiler的原始collapsed数据转换:
_[i] -> __INLINED
_[j] -> __JIT_COMPILED
_[0] -> __INTERPRETED
然后再调用FlameGraph生成SVG。不能从标准SVG反推内联状态。
6. 合并业务worker线程根,避免同一个方法被几十个线程拆成不可见的小方块,但必须保留完整Java调用链。
7. 给出可以直接在SVG中搜索的关键字,例如:
VarHandleReferences.*compareAndSet.*INLINED
VarHandleReferences.*compareAndSet.*JIT_COMPILED
8. 内联结论必须同时满足:
- inline-state火焰图中出现INLINED/JIT_COMPILED差异;
- compiler inline log给出inline或拒绝原因;
- 如有必要,通过反汇编检查是否仍存在bl/call。
不要仅凭标准火焰图中方法出现或消失判断是否内联。
9. 最后给出C2/C3图、原始collapsed数据、JFR、采集命令和结论。明确区分“火焰图观察”“编译日志证据”和“A/B因果验证”。
下次可以直接把下面这段提示词交给大模型:
如果只想用一句短提示词,可以写: