Kotlin Native 静态链接与 rustc 宏卫生热路径

本期检索说明

先读取 content/collections/deep-radar 截至 2026-09-13 的全部原文链接，并按 URL、标题与问题语义去重。最近 24 小时内，Kotlin/Native 的 Linux 静态链接修复同时提供编译器源码、ELF PT_INTERP、退出码、三台机器复现与真实 Ktor 服务验证；rustc 的宏卫生缓存优化则给出完整补丁、官方 try build 与 rustc-perf 全量矩阵。两篇都覆盖了“实测数据、源码证据、原理剖析”三项硬指标。

Java/JVM、Zig 与 Linux 的新材料没有达到同样的证据闭环；Tokio 当日出现的协作调度汇总补丁仍是 Draft，且大量测试由前一期已收录问题延伸而来，语义上重复，因此不凑数。本期收录 2 篇，并优先纳入近期稀缺的 Kotlin/Native 方向。

01 · Kotlin/Native：-static 之后仍写入动态解释器，产物会在 main 前崩溃

原文与日期： youndie，2026-09-13 23:39（中原标准时间）；JetBrains/kotlin PR #8127、KT-89362 与完整可重复实验。截稿时 PR 修改 2 个文件、增加 93 行、删除 2 行，尚未获得 Kotlin/Native code owner 评审，本文不把它写成已经发布的能力。

为什么值得读： 这是一次从“静态二进制无日志段错误”追到链接器 argv、ELF program header 与 Kotlin/Native 编译器源码的完整案例。它没有停在给用户追加神秘 linker flag，而是分别控制 PT_INTERP、NEEDED、glibc/musl、普通/静态路径与真实服务，最终把问题压缩为 GccBasedLinker.finalLinkCommands 中两行无条件参数。

核心技术结论： Kotlin/Native 的 linux_x64 链接命令会无条件发出 -dynamic-linker <path>，而用户的 -linker-option -static 在 29 行之后才进入 linkerArgs。dynamicLinker.linux_x64 只能替换解释器路径，不能阻止 PT_INTERP 段生成。结果是链接器虽然收到了 -static，产物仍声明 glibc loader；Linux 内核据此把本应静态启动的程序交给动态加载器，加载器按动态对象重定位它，进程在任何 Kotlin 用户代码运行前以 139 退出。

补丁没有靠重排所有参数碰运气，而是在生成最终命令时识别用户是否请求静态可执行文件：

private val List<String>.wantsStaticExecutable: Boolean
    get() = "-static" in this

if (!linkerArgs.wantsStaticExecutable) {
    +"-dynamic-linker"
    +dynamicLinker
}

这只解决“解释器不应存在”这一层。konan.properties 中位于用户参数之后的 -Bdynamic 仍可能把后续 -lc 切回共享 libc；作者刻意没有把这个更大、影响所有 Linux 链接的策略改动塞进同一 PR。长期模型应当是为 LinkerOutputKind 增加明确的 STATIC_EXECUTABLE，而不是从字符串列表反推输出类型。

最有价值的实验、源码与 benchmark 细节： 作者用 linker shim 记录真实 argv：-dynamic-linker 位于参数 7–8，用户的 -static 位于 23，工具链自己的 -Bdynamic 位于 32。未修复的同一编译器产物 PT_INTERP=1、退出码 139、无输出；仅去掉动态解释器后 PT_INTERP=0、退出码 0，并完成 hosts 文件、DNS 与普通文件读取。实验脚本在干净 clone 上连续执行两次，又在清空 ~/.konan 的第三台主机执行 cold first run，结果一致。

编译器级验证不只检查参数列表。作者分别构建未修改和打补丁的 2.5.255-SNAPSHOT：用 -linker-option -static 且不再手写 --no-dynamic-linker 时，前者仍是 PT_INTERP=1 / exit 139，后者是 PT_INTERP=0 / exit 0。native:kotlin-native-utils:test 共 10 个测试类、24 项测试全部通过；新静态路径测试在旧实现上确定失败，普通动态可执行文件测试在两边都通过。

真实工程验证覆盖了版本差异。相同三行改动回移到 v2.4.10 后，Ktor、sqlx4k、SQLite、序列化与 KSP 组成的服务仍能运行 migration，在 0.015 秒内启动并监听 8080，未授权 GET / 返回预期 401。普通动态版本仍保留解释器与 7 个 NEEDED 项，说明条件没有误伤默认路径。进一步手工消除 -Bdynamic 后，静态 glibc 服务能运行在只有 musl、没有 gcompat 的 Alpine 容器中；scratch 镜像拉取体积从动态 distroless 方案的 15,542,026 bytes 降至 5,383,000 bytes。不过 musl 原生静态路线仍会在 GC 线程协调中阻塞，属于另一个问题，不能据此宣称 Kotlin/Native 已支持 musl target。

适合的工程师背景： 维护 Kotlin/Native Linux 服务、极简容器或交叉编译工具链，并熟悉 ELF、ld.lld、glibc/musl 与 Gradle Native link task 的工程师。

预计阅读收益： 约 70–100 分钟；能掌握从无日志启动崩溃定位到 PT_INTERP 的方法，理解“静态链接标志”与“静态可执行文件”为什么不是同一件事，并获得一套用 argv、readelf、退出码和真实服务逐层做对照的链接器排障框架。

02 · rustc：宏正文通常只有一个 SyntaxContext，不必先付哈希表成本

原文与日期： Zalathar，2026-09-13 12:24（中原标准时间）；rust-lang/rust PR #162712 与官方 rustc-perf 对比。截稿时 PR 仍是 Draft，try build 已成功，但状态为等待作者处理。

为什么值得读： 这不是把 FxHashMap 换成另一个容器的泛化优化，而是利用宏卫生数据的真实分布：一个 macro_rules! 正文中的 token 通常共享同一个 SyntaxContext，只有“宏生成宏”等高级场景才会出现第二种 context。把最常见的第一个映射内联，就能让绝大多数 token 避开哈希、探测和 map entry 操作，同时保留复杂场景的缓存语义。

核心技术结论： rustc 在 MBE transcribe 阶段为 token span 应用 expansion mark。旧 Marker 只持有 FxHashMap<SyntaxContext, SyntaxContext>，每个 span 都通过 entry(ctxt).or_insert_with(apply_mark) 查询。已有源码注释指出，大多数宏正文只有一个 context，缓存第一次之后通常是 100% 命中；但“命中”仍需计算 hash 并访问哈希表。

补丁在 Marker 中加入一个 first: Option<(SyntaxContext, SyntaxContext)>。第一次看见 context 时直接计算并内联保存；之后如果仍是同一个 original，直接返回 marked。只有遇到不同 context 才退回原有 FxHashMap。因此常规宏的热路径从“每 token 一次 hash-table hit”缩短为一次 Option 判定和一次 context 比较，复杂宏仍保持正确的多 key 缓存。

match self.first {
    Some((original, marked)) if original == ctxt => return marked,
    None => {
        let marked = ctxt.apply_mark(self.expand_id.to_expn_id(), self.transparency);
        self.first = Some((ctxt, marked));
        return marked;
    }
    _ => {}
}
// 第二种及更多 context 才进入 FxHashMap

最有价值的实验、源码与 benchmark 细节： 改动仅触及 compiler/rustc_expand/src/mbe/transcribe.rs，增加 13 行、删除 1 行；try build 成功后由官方 rustc-perf 用固定父提交比较。最可靠的 instructions:u 指标中，45 个 primary 改善样本平均 -0.4%，范围 -0.9% 到 -0.1%，没有 primary 或 secondary 指令回退；28 个 secondary 改善样本同样平均 -0.4%。

资源指标需要保留而不能只报喜。Primary Max RSS 的 8 个显著样本平均 -0.6%，但 secondary 总体为 +2.3%；cycles 的 primary 显著样本混合后平均 -0.5%，同时有 1 个 +0.8% 回退和 4 个 -0.5% 至 -1.3% 改善。Bootstrap 从 493.573 秒增至 498.360 秒（+0.97%），artifact size 从 406.95 MiB 降至 406.91 MiB。指令改善覆盖面广且方向一致，但墙钟与 RSS 仍带噪声和分组反向结果，所以合理结论是“减少了稳定的 CPU 工作量”，不是“所有构建都快 0.4%”。

这项优化的可迁移点是 small-map specialization：当 profile 或数据模型证明 key 基数几乎总为 1，可把第一个 key/value 内联，把通用容器延迟到罕见分支；评估时仍应同时观察对象尺寸、额外分支、复杂输入与全量 workload，而不能只计算哈希调用减少量。

适合的工程师背景： 熟悉 rustc 宏展开与 hygiene，或在编译器、解析器、运行时中优化大量“逻辑上是 map、实际上通常只有一个元素”热路径的工程师。

预计阅读收益： 约 40–60 分钟；能理解 SyntaxContext 在宏转录中的缓存位置，学会用数据分布而非抽象接口选择容器，并正确解读指令数、RSS、cycles 与 bootstrap 之间不完全一致的性能信号。

中国大陆 ToC 硬件价格观察

数据口径

窗口为 2026-08-16 至 2026-09-14，单位人民币。六类硬件继续固定同一 SKU。9 月 14 日实际打开 CPU 固定样本页，页面显示京东最低 ¥2,639，因此新增当日采集点；GPU、主板、DRAM、HDD 与 SSD 页面本次没有返回同日、同型号、同渠道且可复核的新报价，不新增点，也不把旧值复制成今日行情。折线只连接 JSON 中真实采样日，空白尾段表示证据缺失而不是横盘。

价格来源： 9800X3D、MSI RTX 5070 VENTUS 3X、ASUS TUF B850M-PLUS WIFI7、Kingston FURY DDR5-6000 32GB、IronWolf Pro 8TB、ZHITAI Ti600 2TB。GPU 供给判断继续参考 2026-07-27 的中国区 RTX 50 系列渠道调价记录。

判断依据

CPU 的新点不是笼统市场均价，而是同一聚合页显示的京东最低价；它从 9 月 9 日的异常低点反弹 ¥190，说明低点尚未形成稳定平台。GPU 有截至昨日的连续同价证据但今日未新增；其余类别新鲜度更低，只保留历史轨迹。SSD 的最低价与前序价格差过大，继续把它视为需要核验规格和渠道的事件，而非全市场下跌。建议只依据已观察价格与公开渠道变化，不对不可见库存或产能作推测。

其它你可能关心的

• rustc：已初始化的依赖反向索引直接读取 OnceLock，避免重复进入构造路径
• Tokio：集中补齐 always-ready 与 Interrupted I/O 的协作预算
• OpenJDK JFR：修复零 cutoff 的不同时间单位导致 path-to-gc-roots 配置被忽略

本期结论

两篇材料都在消除“通用机制无条件介入热路径”的代价：Kotlin/Native 无条件写入动态解释器，让静态输出在内核加载阶段失败；rustc 无条件进入哈希表，让单一 hygiene context 的普通宏重复支付通用 map 成本。工程上更可靠的设计是先把输出模式和数据基数表达清楚，再让复杂机制只出现在确实需要它的分支，并用二进制结构或全量性能矩阵验证，而不是从参数名或局部墙钟时间推断结果。