Runtime

47 篇内容

工程实践Cloudflare Blog

Supporting native Rust in Workers with the new Emscripten target for wasm-bindgen

文章介绍 Cloudflare 在 wasm-bindgen 与 Rust Workers 上实验性支持 wasm32-unknown-emscripten 目标,使原生 Rust 代码乃至 Tokio 应用可在 Workers、Node.js 和 Web 上运行。核心工作包括通过 -sWASM_BINDGEN 让 Emscripten 与 wasm-bindgen 协同,补丁支持 libc、socket2、Mio 等库,并为 Tokio 设计 JSPI 挂起语义和 LocalEventLoop 事件循环集成。为解决 Tokio I/O,作者用 node:net 桥接 Emscripten 的 epoll/TCP/UDP socket,并贡献 -sNODERAWSOCKETS。文中以 Pumpkin Minecraft 服务器跑在 Durable Object 为例,验证多人、持久化和 TCP 入口可行性。当前仍为预发布实验补丁,上游评审、JSPI 重入上下文和 API 稳定性尚待完善。

推荐收录:文章给出 wasm-bindgen/Emscripten 互操作、Tokio 在单线程 JS 事件循环中的两种集成方案,以及 epoll/socket 桥接的完整工程证据,并用 Minecraft 服务器验证可行性。对 Rust、WebAssembly、边缘运行时、异步运行时和网络栈开发者有较高迁移价值;需注意当前仍是实验性补丁,上游 API 与实现可能变化。

技术文章Daniel Lemire

How many strings can you create per second?

文章用微基准测试比较多种编程语言每秒能创建多少条由整数转换而来的短字符串,覆盖 C++ 的 std::to_string、Nim 的 $、Go 的 strconv.Itoa、Node.js/Bun 的 String、Rust 的 to_string 与 itoa,以及 Python 的 str。方法上让循环把结果写入 1024 槽环形缓冲,整数从 0 到 1 亿,每字符串最多 8 位,在 Apple M4 Max 上取五次最佳成绩。结论是 C++ 以 183.8M/s、约 5.4ns 每条大幅领先,Nim、Go、Node.js、Rust 集中在 63-86M/s、12-16ns 区间,Python 最慢,为 22.9M/s、约 44ns。作者解释 C++ 优势来自小字符串优化,短字符串直接存在对象内,无需调用内存分配器;Go 和 JavaScript 等 GC 运行时分配大量短命小对象也相当高效。边界是该结果依赖特定硬件、编译器版本、字符串长度和分配模式,属于微基准,不宜直接外推到所有真实工作负载。

推荐收录,因为它给出了可复现的微基准方法、完整源码和版本信息,并用小字符串优化与 GC 分配差异解释跨语言性能差距。适合关注性能、运行时和语言实现的开发者,可作为评估字符串/对象分配热点的参考。风险是数字依赖 M4 Max 和具体版本,不能直接当作跨平台结论。

工程实践Cloudflare Blog

Python Workers are now generally available

Cloudflare 宣布 Python Workers 正式 GA,使 Python 成为 Workers 一等运行时,并原生支持 Workers AI、R2、D1、Queues 等绑定。文章解释其基于 WebAssembly 与 Pyodide,通过 workers.asgi/wsgi 连接器桥接 ASGI/WSGI,让 FastAPI、Django 等框架无需服务器即可运行。为解决 WASM 沙箱缺少 TCP socket,团队用 Workers connect API 实现 socket 系统调用桥,以支持 Hyperdrive 连接 PostgreSQL/MySQL,并使 openai、langchain 等库可用。团队还推动 PEP 783 与 cibuildwheel 标准化包生态;文章适合平台/运行时工程师,但属厂商 GA 公告,缺少独立性能基准和长期边界分析。

推荐收录。文章虽为 GA 公告,但给出了可验证的工程实现证据:用 Pyodide/WebAssembly 承载 Python、实现 ASGI/WSGI 桥、用 Workers connect API 补齐 socket 系统调用,并推动 PEP 783/cibuildwheel 标准化包构建。对边缘运行时、Serverless 平台和 Python Web/AI 应用开发者有迁移价值;需注意其厂商视角,缺少独立性能对比和长期兼容性边界。

工程实践Null Program

A custom virtual machine for the Stars! 4X game

文章介绍作者为 1995 年的 16 位 Windows 4X 游戏 Stars! 构建 Stars!VM:它内嵌 80286 模拟器和 Win16 到 Win32 桥,使老游戏以原生 Win32 程序运行,并保留现代文件选择器与 4K 缩放。模拟器直接调用宿主 x87 硬件处理 80 位浮点,并用差分模糊测试随机指令与 JIT 结果对比来验证正确性;桥接层负责映射句柄、转换结构布局和处理 DOS 中断。作者还通过 MCP 暴露 UI DOM 与客户机内存,让 AI 代理注入事件甚至完整试玩一局。性能上,基于指令 trace 反向工程热点例程并改写为新 80286 指令,使回合生成约提速 2 倍,同时缓冲 I/O、原生实现 WaveMix.dll、压缩资源,并注入序列号和固定硬件签名绕过拷贝保护。方案依赖 x86/x86-64 与 SSE2,且不实现软件 x87,适用边界较明确。

推荐收录。文章给出一个真实且完整的遗留系统复活案例:从 80286 仿真、Win16/Win32 桥接、差分模糊验证,到 trace 驱动热点优化和 MCP 代理接口,都有具体约束、取舍与验证证据。适合对模拟器、系统编程、逆向工程和遗留软件迁移感兴趣的读者,其中的差分测试、指令级补丁和 I/O 缓冲思路可迁移到其他兼容层或运行时项目。

工程实践Oxide Public RFDs

RFD 0609: Futurelock

RFD 609 提出并系统分析了 async Rust 中的 futurelock:一个任务负责轮询多个 Future,却停止轮询持有共享资源的 Future,导致其他 Future 永久等待。文章用可复现的 tokio::select! 示例说明,当分支使用 &mut future 且在其他分支的 handler 中 await 时,已启动但未完成的 Future 不会被取消,锁的等待队列和 select! 的提交行为共同造成死锁。作者还复盘了 Omicron 中数据库访问全部挂起的真实故障,给出通过 DTrace 定位 mpsc 发送阻塞的调试线索。确定部分给出了规避建议:避免任务停止轮询已启动的 Future,优先用 tokio::spawn 或 JoinSet,谨慎在 select! 分支中 await,并重新审视有界通道的阻塞 send 模式。局限是问题高度依赖运行时语义,调试困难,且没有一劳永逸的抽象或编译器检查,需逐例判断。

推荐收录,因为它把一次真实线上挂起抽象为可复现的 futurelock 机制,并给出 tokio::select!、Mutex 等待队列、任务轮询职责之间的因果链。对使用 async Rust/Tokio 的工程师、维护高并发服务或做代码评审的人有直接迁移价值;局限是结论依赖运行时语义,调试与规避仍需逐例判断。

工程实践Oxide Public RFDs

RFD 0397: Challenges with async/await in the control plane

该 RFD 讨论 Oxide 控制平面使用 Rust async/await 三年后暴露的任务取消安全问题:Future 在 await 点被 drop 或 task 被 abort 时,内部状态会被丢弃,可能导致互斥锁在保护的不变量恢复前释放。作者用同步 Mutex 与 tokio Mutex 的对照示例复现状态机不变量被破坏,并列出 Dropshot 请求处理、tokio::select!、timeout、try_join 等取消来源。文章指出 tokio 对 cancellation safety 的说明零散且不完整,编译器无法检查,审计成本高。短期内通过让 Dropshot handler 独立成 task 缓解,长期需讨论是否迁移同步线程模型或制定取消安全规范。该文不提供完整解决方案,重点在界定问题、风险与取舍边界。

推荐收录,因为它以 Oxide 真实控制平面 bug 为例,给出可复现的同步/异步 Mutex 对照代码,并系统梳理任务取消安全的来源、风险与 FAQ 取舍。对使用 Rust 构建分布式后端、维护长期控制面或评估 async 架构的读者,文中的 await 点不变量、取消传播和短期缓解策略具有直接迁移价值;需注意它聚焦问题界定,不提供完整解决方案。

技术文章Go Blog

Size-Specialized Memory Allocation

文章介绍 Go 1.27 引入的按大小特化的内存分配,针对小于 80 字节的堆分配生成专用 mallocgc 变体。作者解释 span class 如何编码尺寸等级与是否含指针,并据此为 tiny 及各非 tiny span class 生成函数;编译器已知大小时可直接调用,否则由 mallocgc 动态分派并回退通用路径。优化包括常量大小下直接清零、免去 span class 计算、手工内联和慢路径拆分,同时需权衡代码体积与指令缓存占用。基准显示小对象分配快 20-30%,分配密集程序最多快 1%,16/24 字节收益最大;收益随尺寸增大而减小,并受 GC 活跃等边界影响,可用 GOEXPERIMENT=nosizespecializedmalloc 关闭。

推荐收录:这是 Go 官方博客对运行时与编译器协同优化的完整实现说明,包含基准数据、指令缓存权衡,以及用生成器避免特化代码漂移的做法。适合 Go 开发者、运行时/编译器工程师和性能优化读者,可迁移到其他语言运行时的分配器特化与代码体积取舍。注意结论版本特定,关闭开关应仅作为问题排查手段。

工程实践Cloudflare Blog

How we rebuilt Cloudflare Workers’ module registry for Node.js compatibility

本文介绍 Cloudflare 重写 workerd(Workers 运行时核心)模块注册表的工程实践。旧实现按文件系统路径而非 URL 解析 specifier,会预编译整个 Worker 包并让每个 V8 isolate 保存私有副本,带来 import.meta 缺失、解析不一致和重复编译开销。新注册表以 URL 为 specifier 基础,支持 import.meta.url/main/resolve、查询字符串隔离模块实例、import attributes 校验,并实现 Node 的 require(esm) 语义与统一错误行为。代码改为懒编译,并支持跨 isolate 共享及 WebAssembly source phase imports。该能力须显式开启 new_module_registry compatibility flag,尚未默认启用,旨在解决运行时与打包器的模块兼容问题。

推荐收录,因为文章不是泛谈 Node.js 兼容,而是从旧注册表的解析路径、复制编译等真实约束出发,梳理迁移到 URL 语义后的 API 行为和边界条件。适合运行时开发、模块系统研究者或需要维护打包器/兼容层的工程师阅读,其懒编译、错误一致性和 flag 迁移策略可作为同类演进设计的参考。

技术文章The Consensus - Articles

Data races and the limits of ThreadSanitizer in C and Go

文章以 C 和 Go 为例解释数据竞争定义,并指出 ThreadSanitizer(TSan)文档不足、实现已到 v3。作者用 Python 实现理想化的多线程 C 子集解释器,再接入 FastTrack 风格向量时钟作为竞态检测器,展示 TSan 的大致原理。随后通过可复现实验说明 TSan 的资源预算盲区:255 线程槽、14 位同步释放计数、每 8 字节 4 个访问单元都可能溢出,导致漏报明显竞态;Go 的 sync.Pool 地址哈希复用也会掩盖竞态。结论是 TSan 仍很有价值,但无报告不等于无竞态,使用者需理解其适用边界。

推荐收录。文章不是泛泛介绍竞态,而是通过自建解释器和检测器、C/Go 可复现实验,直接展示 TSan 在 255 线程、计数器、访问槽和 sync.Pool 上的漏报机制,证据具体且可迁移。适合使用 C/Go 并发、维护 CI 竞态检测或研究动态分析工具的读者,能帮助建立“无报告≠无竞态”的判断,并指导压测与人工复核。

工程实践Xe Iaso

It took a year to ship WebAssembly in Anubis

文章讲述作者花一年把 WebAssembly 工作量证明引入 Go 反爬服务 Anubis 的完整工程经过。原实现需在 JavaScript 与 Go 间维护两份代码,且难度按前导半字节计数、最坏情况加一级会放大千倍;新方案用 Rust no_std 生成 wasm32-unknown-unknown 二进制,由浏览器和服务器执行同一份产物,并使用 argon2id 内存硬算法改善手机端体验。文中详述了无法使用 WebAssembly Component Model 时如何手工设计三缓冲 ABI、为兼容 Chrome 75 做 SIMD 拆分与 wasm-opt 特性裁剪,以及如何用 wasm2js 兜底禁用 WebAssembly 的浏览器。工程陷阱包括首次遇到的 LLVM 编译器 bug、rust-std 预编译导致旧浏览器崩溃,作者用提交构建工具与 chromesweep 旧浏览器测试应对。功能计划在 v1.28.0 默认关闭,v1.29.0 根据反馈再决定是否打开,并保留了若干已知边界。

推荐收录。文章是真实项目的一手长程复盘,明确写出了共享二进制方案、手工 ABI 限制、旧浏览器兼容成本和编译器工具链意外,并保留已知问题而不是包装成完美故事。适合研究 WebAssembly 模块化、反爬 PoW 或 Go/Rust 混合构建的工程师,其可复现构建、特性裁剪和多版本浏览器测试思路可直接迁移到同类项目。

技术文章知乎 - 腾讯技术工程

DeepSeek Harness背后的“心脏”:Cordis 到底是什么

本文以腾讯技术工程的角度系统介绍 Cordis 插件化应用框架,说明它如何成为 DeepSeek Harness 的运行时核心。文章首先梳理插件系统需要解决的安装、配置、卸载与协作四个问题,并引入作者 Shigma 及其 Koishi 技术栈。随后详细介绍 Cordis 的核心机制:插件、上下文、fiber、可逆副作用、响应式注入、事件与 Schema,并解释这些机制如何支撑“配置即程序”、热重载和依赖自动重连。文章还结合 DeepSeek Harness 实际源码,展示启动流程、工具流水线、自指设计等。后半部分重点解读配套论文《A Programming Paradigm for Spatiotemporal Composability》,说明其将 effect 与 coeffect 形式化,证明动态组合下的卸载恢复、依赖协调和配置收敛。文中也通过与传统 DI、React、OSGi、微服务等对比,指出 Cordis 的适用边界与对自进化 Agent 的潜在价值。全文技术密度高,兼顾理论与实践,但需注意示例与数据基于 DSH 0.1.0-rc.6 及 2026 年 8 月的生态快照,部分内容具有较强的时效性。

收录理由是文章不是浅层功能介绍,而是对 Cordis 框架的设计哲学、生命周期机制、依赖模型和形式化证明做了系统剖析,并紧密关联 DeepSeek Harness 的真实工程实践。适合对插件系统、Agent 运行时、依赖注入或框架设计感兴趣的工程师与研究者阅读。文中关于可逆副作用、响应式依赖和配置对账的论述具有跨场景迁移价值,理论对比也为评估同类框架提供了清晰坐标系。

科研议题Max Bernstein

Support Local Variables

这篇博客由 CRuby 编译器团队成员撰写,围绕新论文《Support Local Variables》介绍了 ZJIT 编译器如何处理 Ruby 局部变量的复杂语义。ZJIT 是继 YJIT 之后的新方法级 JIT,基于 SSA 的高层中间表示,并带多个全局/局部优化 pass。与其他 Ruby 编译器的处理方式不同,ZJIT 直接将局部变量提升为 SSA 值,而不是继续使用内存读写或依靠部分求值恢复 SSA。文章指出 Ruby 局部变量的动态语义在正确性和优化上都有不少陷阱,并总结了作者在 ZJIT 中的解法;该论文也是首篇正式记录 ZJIT 的学术文献,发表在 VMIL 2026。博文本身是论文的摘要与背景介绍,完整的实现细节仍需查阅引用的 PDF。

这是来自 CRuby/YJIT 团队的一手技术分享,明确给出了 ZJIT 的定位、SSA 表示和局部变量优化的设计选择,并有论文和学术发表作为支撑。适合编译器实现者、语言设计者和虚拟机研究者阅读,可借此理解动态语言局部变量在 SSA 化时的语义难点,以及一种不同于内存标量替换的方法。由于博文篇幅有限,实际优化细节和边界在 PDF 中,阅读时应以论文为主,避免仅凭摘要下结论。

技术文章Go Blog

Goroutine Leak Profiles

本文介绍 Go 1.27 引入的 goroutine 泄漏分析器:一种利用运行时垃圾回收进行精确泄漏检测的新机制。作者先定义泄漏为协程永久阻塞在不可能满足的共享原语上,并指出 goleak、synctest 只能覆盖测试场景。新分析器将 GC 的标记根改为非阻塞协程,通过可达追踪逐步识别被活协程引用的同步原语,从而把不再可达的阻塞协程标记为泄漏。文中给出 Worker 并发、双发送、早退、超时等模式,并展示 CockroachDB、etcd、Kubernetes、Moby 的真实泄漏案例及修复方法。实现上复用 GC 但会增加并发标记开销,且仅能检测阻塞在 channel 与 sync 原语上的泄漏,对 IO 等待和全局引用长期存活的情况存在盲区。

推荐收录。这是 Go 官方博客对 1.27 新功能的权威解读,既有清晰的泄漏定义和实现原理,也包含多个来自工业界的可复现案例与修复方案。无论是要在生产环境排查并发泄漏的 Go 开发者,还是想理解 GC 如何复用为调试工具的运行时研究者,都能获得可迁移的启发。主要风险是该机制适用范围有限(仅同步原语阻塞),读者需注意其局限。

技术文章知乎 - NGINX洪志道

一个应用服务器是怎么工作的

文章系统拆解应用服务器的工作原理,衔接外层 Web 服务器与语言运行时,分析其如何接收请求、管理进程并调用应用代码。作者将应用服务器分为两类:一类直接用应用语言实现 HTTP 服务并运行同生态代码,另一类用 C/C++/Rust 等系统语言实现服务器核心,通过语言适配器加载解释型语言引擎。文章以 PHP-FPM、Gunicorn、Uvicorn、NGINX Unit 等为例,解释 SAPI 与 Zend Engine、WSGI/ASGI 等接口差异,并阐述固定进程池、动态进程池和按需进程池的取舍。随后文章跟随一次请求从 accept 到语言运行时调用再到返回响应的完整链路,说明请求解析、应用选择、进程获取、适配器转换及错误分层。最后讨论应用服务器应负责多少功能的分层设计,强调统计应放在应用执行与响应返回的边界。文章基于通用部署模型,忽略具体协议细节,适合作为理解应用服务器基础架构的参照。

推荐收录。文章由 NGINX 背景作者写作,澄清了 Web 服务器、应用服务器、语言运行时时常被混淆的分层关系,并用一次请求的完整路径串联进程管理与语言适配等细节。适合初入后端的开发者建立系统认知,也适合需要设计或选择应用服务器形态的工程师作为思考框架;文中对多语言支持难点的分析具有普遍参考价值。

工程实践知乎 - NGINX洪志道

聊聊 NGINX 作者 Igor Sysoev 的遗珠之作:Unit

文章是 Unit 核心维护者对 NGINX Unit 的一手回顾。它指出 Unit 的定位是在 NGINX 之后再向前一步,用统一基础设施直接加载并管理 PHP、Python、Go 等应用进程,把配置变成可通过 REST API 修改的运行时对象树。文章解析了 router 多线程事件循环、任务队列、基于 port 的进程间通信,以及应用进程自动扩缩中对 pending、空闲、就绪和崩溃的生命周期处理。作者结合与 Igor 共事的经历,强调架构控制复杂性的能力,并指出 Unit 因市场定位与生态未闭环而在 2025 年归档。

推荐收录。文章由 Unit 核心维护者撰写,包含真实系统设计细节和一手维护经验,对 router 并发模型、动态配置与进程生命周期有扎实剖析。适合 Web 基础设施、应用服务器和系统设计方向的工程师阅读,可迁移的是对复杂状态和并发边界的工程判断。需要注意项目已停止维护,读者应结合当前生态评估其模式适用性。

工程实践Simon Willison

A shot-scraper-style JSON API on Bun 1.4's new Bun.WebView

本文介绍了 Bun 1.4 发布的新特性,重点剖析了 Bun.WebView——它将浏览器自动化能力内置到 Bun 运行时,支持通过 macOS WebKit 或 CDP 控制 Chromium。作者参照自己的 shot-scraper javascript 工具,用 Claude Code 辅助构建了一个 TypeScript JSON API 原型,用于加载网页并执行 JavaScript。实验通过 cgroups 限制容器内存,评估该服务在复杂网页上运行完整 Chrome 所需的内存上限,结果显示约需 192MB-256MB。文章还提到了 Bun 1.4 的其他变化,如 Rust 重写、性能和兼容性提升。该实验针对单实例服务,内存需求会随页面复杂度和并发数变化,适用于基于 Bun.WebView 的轻量级浏览器自动化工具设计。

推荐收录。文章来自长期关注 Web 开发的 Simon Willison,对 Bun 1.4 的新 API 做了实际验证,给出了明确的内存占用数据,属于可复制的技术测量。适合想用 Bun.WebView 构建浏览器自动化服务的开发者,尤其是做内存预算和容器规划的读者。其测量方法和 API 使用方式可迁移到类似场景,但需注意测试范围较窄,生产环境需进一步验证。

技术文章Fzakaria Blog

Three ways to smuggle SQLite into Nix

文章以 nixpkgs-multiverse 的索引文件为背景,探讨如何在 Nix 求值过程中直接调用 SQLite 查询,避免大规模 JSON 整文件解析。作者依次介绍 builtins.exec、builtins.importNative、巨型 .nix 文件和 builtins.wasm 四种方案,并给出关键代码和基准。结果表明:fromJSON 与巨型 .nix 均为固定开销,exec 每条查询约 3.8ms,importNative 因句柄缓存几乎恒定,wasm 需约 2.5s 编译但查询仅 7ms/条。作者最终认为当前无一种适合正式发布,同时指出 wasm 的潜力。文章还覆盖 Nix 字符串无法表示二进制等边界问题。

推荐收录。文章以可复现代码和实测基准系统比较了四种在 Nix 中嵌入 SQLite 的方案,并坦诚列出各自的安全与性能缺陷。适合 Nix 扩展开发者和需要在构建/求值流程中内嵌查询能力的读者;其对比方法和性能分析可迁移到其他“运行时内嵌外部引擎”的场景。注意 builtins.wasm 仍属实验特性,相关 API 可能变化。

工程实践DuckDB Engineering Blog

DuckDB v2.0: Your Database Deserves a Better Parser

本文是 DuckDB 工程团队关于 v2.0 用 PEG 解析器替换 PostgreSQL 派生解析器的深度技术说明。文章先阐明解析器在查询流水线中的角色,并区分了 DuckSQL 方言与解析器实现本身。接着指出旧的 YACC/Bison LALR(1) 解析器在扩展语法时容易引入 shift/reduce 冲突,而 PEG 通过有序选择避免了这类冲突。工程化过程中,作者重点解决了回溯导致的指数级重复工作,借助 packrat 记忆化使得恶意输入(如大量未闭合括号)的解析时间从指数级降为近乎常数,并给出实测数据。文章还演示了运行时扩展语法的方法:扩展可注册自定义规则并复用 DuckDB 既有语法与转换函数,以 Google pipe query syntax 为例展示了从语法到 AST 的完整过程。最后说明扩展 API 仍是预览,若发现现有查询行为不一致可提交 issue。该文对数据库解析器设计、语法扩展机制和解析性能优化具有长期参考价值。

本文基于真实工程改造,给出了从动机、原型到生产化的完整路径,包含 packrat 记忆化解决指数级回溯的性能对比数据,以及通过扩展点复用现有语法和转换函数的具体 API 示例。适合数据库内核、编译前端或开发者工具方向的工程师阅读。文中的运行时语法扩展思路与回溯性能治理方法可以迁移到其他解析器或语言实现;需注意扩展 API 仍为预览,兼容性验证细节未完全展开。

科研议题Cloudflare Blog

A revisit of remote Spectre attacks on Cloudflare Workers

本文是 Cloudflare 对其 Workers 平台远程 Spectre 攻击风险的重新评估,并发布了共同署名的研究论文。文章回顾了 2021 年基于动态进程隔离(DyPrIs)的防御措施,随后利用 2024 年至 2025 年初的新技术,在生产环境中构建了更新的攻击原型。攻击通过组合 V8 类型混淆瞬态指令、PLRU 缓存替换策略的信号放大、远程 WebSocket 定时器以及 Durable Objects 维持长期执行上下文,绕过了原有 DyPrIs 的检测,实现了 12 bit/s、准确率 99% 的跨隔离区内存泄漏。文章还详细说明了攻击受限于生产噪声、需要校准和统计分类,并指出 DyPrIs 因按调用结束后隔离和 iTLB 归一化而被规避。防御方面,Cloudflare 部署了 V8 Sandbox、基于 MPK 的进程内隔离、并改进了 DyPrIs 对长生命周期 I/O 密集型执行的检测。作者强调当前攻击已被缓解,且在三年内未发现实际利用迹象。

推荐收录:这是一篇罕见的生产环境实证安全研究,作者完整展示了从攻击原语搭建、噪声规避到防御改进的闭环,而非单纯理论推演。对研究 CPU 侧信道、云平台隔离或运行时安全的读者,文章中的攻击工程化方法和防御边界分析具有很高的迁移价值,还能帮助安全工程师理解 Spectre 类漏洞在真实多租户环境中的可利用性和缓解局限性。

技术文章Daniel Lemire

Go 1.27 will make some allocations cheaper

文章以Go语言的内存分配机制为背景,对比栈分配和堆分配的成本差异。堆分配需要回收管理,且Go中返回指针或逃逸变量时也会进入堆分配。Go的堆分配器按尺寸类(8字节、16字节等)取整,并带有额外开销。作者指出Go 1.27以前所有堆分配都走通用函数,1.27开始对小于80字节的小对象使用专用分配路径,以减少函数调用和尺寸类查找。基准测试显示,16字节且含指针的节点分配从9.5ns降至5.5ns,提速约1.8倍。文章同时说明该优化仅对大量小对象分配的程序有效,并非所有负载都能受益。

推荐收录。文章用可复现的基准测试直接量化了Go 1.27小幅优化带来的分配性能提升,并解释了栈/堆分配原理与尺寸类机制,内容深入且边界清晰。适合关注Go性能调优、运行时分配或做性能评测的开发者阅读;其“用小路径替换通用路径”的优化思路也可迁移到其他语言的性能设计。需注意结论限于小对象分配场景。

技术文章Thomas Schatzl

JDK 27 G1/Parallel/Serial GC changes

本文由 HotSpot GC 开发者撰写,综述了 JDK 27 中停止-世界(STW)收集器(G1、Parallel、Serial)的变更。最重要的变化是 JEP 523 使 G1 在所有环境中都成为默认垃圾收集器,彻底取代了 Serial GC 在某些场景下的默认地位。文中详解了 G1 的堆大小调整逻辑修正(不再受 Min/MaxHeapFreeRatio 影响)、自适应并发标记改进、大对象回收与弱引用交互的 bug 修复。Parallel GC 获得了自适应年龄阈值双向调整和堆扩容修复。还提及了 TLAB 大小优化和字符串去重增强。文章内容聚焦于特定 JDK 版本,不涉及 ZGC 等并发收集器,但提供了来自核心实现者的直接解读。

推荐收录,因为文章来自 OpenJDK 长期 GC 贡献者的一手总结,系统梳理了 JDK 27 中 G1 和 Parallel GC 的关键行为变更、现有缺陷修正及设计动机,引用特定 bug ID 并提供背景解释。对于需要升级 JDK、调试 GC 问题或调优 JVM 的性能工程师和后端开发者,这些细节可直接指导实践,避免性能回退,并理解默认开关背后的工程考量。

技术文章LWN.net

[$] Bringing BPF to binfmt_misc

文章介绍了 Linux 内核的 binfmt_misc 机制,该机制允许用户空间配置任意可执行文件格式的透明执行。作者分析了现有机制的局限,并重点讨论了即将引入的 BPF 支持,使内核可以通过 BPF 程序动态决定如何运行给定程序。更新旨在提升灵活性和可编程性,同时保持向后兼容。文章还涉及相关安全考量、性能影响以及潜在的实现挑战,适合关注内核运行时可扩展性的技术人员。

LWN 文章深度解析了内核二进制格式处理的演进,详细说明了 binfmt_misc 与 BPF 结合的动机、原理和设计权衡,为系统软件开发者提供了可迁移的运行时扩展思路,适合研究内核和自定义执行环境的读者,长期参考价值明确。

技术文章matklad

Zig's Io.Threaded is Neat

本文深入解析Zig语言标准库`std.Io.Threaded`的实现,重点介绍其如何在阻塞线程模型中可靠支持取消操作。作者先区分并发与并行,指出取消是并发的本质特征,而传统线程因系统调用阻塞难以取消。然后详细说明在POSIX上通过信号与共享内存标志位协作的取消协议,以及Windows上使用`NtCancelSynchronousIoFile`的更直接方式。文章还对比了Java线程中断和`pthread_cancel`的不足,并分析Zig在接口层面将`async`与`concurrent`分离的设计优势,从而在用户态实现清晰的取消语义。内容深入系统调用、运行时和语言设计的交界,展示了将一个“怪异”想法工程化落地的细节,但方案依赖特定平台机制,且线程池复用等工程权衡未充分展开。

推荐收录,因为本文不是泛泛介绍Zig特性,而是对并发取消这一底层难题给出具体实现解析,从信号/标志位协议到接口设计取舍均有清晰论述,并提供了跨平台对比。适合系统编程、语言运行时和并发模型设计者阅读,其按平台中断syscall的思路以及分离异步与并发的接口设计可供其他语言或框架参考。

技术文章知乎 - 孔某人

谈一个AgentOS早期征兆,谈Agentic Job Runtime

文章从Agent执行长程任务时状态管理困难的问题出发,提出了Agentic Job Runtime的概念。作者指出,当任务涉及大量共享资源、优先级调度和动态规划时,单一Agent通过文档更新状态容易丢失信息,因此需要引入队列、数据库表等传统数据结构,并采用多Agent主从架构(类似蜂群或主从式并发)来管理状态和流水线执行。该Runtime类似现代编程语言运行时,需支持状态持久化、恢复、回滚、不同LLM配置,以及可视化和权限控制。文章最后辨析了与Agent OS的区别,认为它不是对底层资源的封装管理,而是面向单个Job的执行环境,可能是Agent OS最早落地的方向。整体提供了一种务实的系统设计思路,适合大规模Agent工程场景。

文章不是空泛的概念讨论,而是给出了具体的技术方案和工程架构,对解决Agent复杂状态管理和任务协调有实际指导价值。适合AI工程师、Agent框架开发者和对多Agent系统感兴趣的研究者,其设计思想可迁移到需要长程、多任务并发的Agent系统中。

技术文章Fzakaria Blog

Seriously, what is the large code-model even for?

文章深入分析 x86-64 大代码模型(-mcmodel=large)在处理线程局部存储(TLS)时的根本性缺陷。作者通过构造超过 2 GiB 的 .bss 和 .text 示例,对比普通数据访问与 TLS 访问的编译器重定位类型,指出尽管大代码模型为普通数据生成了 64 位重定位,但 TLS 访问序列仍使用 32 位立即数(如 R_X86_64_TPOFF32),导致二进制文件超出 2 GiB 时链接失败。进一步剖析 GCC 与 LLVM 生成的指令序列,揭示问题并非编译器实现缺陷,而是 x86-64 psABI 从未定义大代码模型下的 TLS 访问模式,使得 64 位 TLS 偏移无法编码到指令中。文章提供了可复用的 Python 脚本用于生成巨型目标文件,验证了现象的通用性,并指出该限制对有大量线程局部变量的静态链接可执行文件尤为严重。

本文并非泛泛而谈,而是通过可复现的构造实验和汇编级分析,定位到 x86-64 ABI 规范的一项具体缺失,揭示了大型二进制工程中的一个隐蔽陷阱。其直接证据清晰、方法可迁移,适合从事工具链、系统软件或性能敏感大型应用开发的读者参考。文章还提供了生成测试用例的脚本,有助于读者在自己的环境中验证和延伸研究,具备长期的参考价值。

工程实践Datadog Engineering

Unbiased Java CPU profiling with JFR in JDK 25

本文介绍了JDK 25中JFR新增的CPU时间采样事件,旨在解决传统Java profiler因依赖JVM内部未公开接口而导致的CPU分析偏差。作者详细阐述了由Datadog、SAP、Amazon等公司和OpenJDK社区共同推动的设计背景,解释了新事件如何基于操作系统线程调度数据实现无偏采样,避免基于栈采样或线程跟踪的常见误差。文章还讨论了该事件的实现原理、性能开销、使用方式以及与现有JFR事件的集成,并说明了其适用于Linux等支持OS级线程调度的平台。该工作为Java应用性能分析提供了更可靠的CPU数据基础,但对JDK版本和操作系统有要求。

本文深入剖析了JDK 25 JFR CPU时间采样事件的工程背景和实现细节,是由多家企业合作解决真实性能分析问题的案例,具有明确的长期技术参考价值。适合Java性能工程师、JVM研究者和可观测性平台开发者阅读。文中展示的偏差分析方法和跨社区协作经验可迁移至其他性能工具的设计与改进,帮助读者理解无偏CPU profiling的难点和解决方案。

工程实践Fzakaria Blog

Linux kernel will support $ORIGIN, sort of

文章记录了作者为支持 Nix 的 relocatable binaries 而向 Linux 内核提交补丁的完整过程。最初尝试在 VFS 层直接支持 $ORIGIN 失败后,在 VFS 维护者 Christian Brauner 的建议下,转而利用 eBPF 和 binfmt_misc 实现可编程解释器选择。最终方案通过 eBPF 程序在运行时根据 ELF 文件路径动态确定解释器,无需修改内核主体,并衍生出新的分发模式(如 loader substitution 'L')以解决传统 binfmt_misc 导致的进程身份透明性问题。文章还讨论了该机制在 QEMU、shebang 等场景的扩展潜力,并保留了向后兼容性设计——通过新增 PT_INTERP_NIX 段来控制触发。作者展望了在 NixOS 中的集成计划,同时坦诚说明了内核参与门槛、eBPF 所需的配置依赖等边界。

该文以一线开发者的视角完整呈现了一项内核特性的工程实现路径,从问题定义、社区协作、技术方案演化到最终合入主线的全过程,具有很高的可迁移价值。对从事包管理、容器化或需要定制可执行文件加载流程的工程师而言,它不仅展示了 eBPF 在系统软件中的创新用法,还深入分析了 binfmt_misc 的传统缺陷与改进思路,是理解现代 Linux 可执行文件加载机制和内核贡献方法论的良好参考。

工程实践知乎 - NGINX洪志道

06|从哪个功能开始:最小、核心的流式处理

文章围绕一个 NGINX Lua Web runtime 的开发顺序选择展开,核心结论是应先实现 Stream,而不是先做 Headers、Request 或 Response。作者认为 body 才是请求、响应与 fetch 的共同底座,只有先把流式数据模型立住,后续 API 才不会停留在表层封装。文章进一步分析了流式处理的复杂性:它同时涉及客户端、上游和 Lua 自身创建的流,还要处理生产端、消费端、异步等待、状态保存以及 NGINX 事件与 Lua coroutine 的协同。作者指出,Headers 虽然更容易实现、也更适合快速出成果,但对系统最核心的异步与数据流问题牵引不足。本文的价值在于用最小可验证功能暴露架构关键点,帮助读者理解如何用功能排序来对抗复杂性。

推荐收录,因为文章明确给出了“先做 Stream、后做 Headers”的工程证据,并解释了 body 作为 runtime 底座为何决定整体架构形态。适合做 Web runtime、异步 I/O 和系统设计的项目规划参考,但它更偏方法论与阶段选择,尚未给出完整实现细节。

工程实践MaskRay

A deep dive into SmallVector::push_back

这篇文章围绕 LLVM SmallVector 的 push_back 热路径优化展开,分析了约 trivially copyable 元素在容量不足时为何会把本应只发生在慢路径的状态保存,意外带到快路径上。作者通过 clang、GCC 和不同库实现的汇编对比指出,fast/slow 合流会迫使 this 和元素值占用被调用者保存寄存器,shrink wrapping 无法消除这些开销。随后提出把 grow-and-store 拆成独立的尾调用慢路径,让快路径只保留一次比较、一次存储和一次递增,从而显著缩短指令序列并减少寄存器压力。文章还验证了 libc++、libstdc++、Boost small_vector 的类似问题,并说明这个改动对二进制体积、编译时指令数和少数内联阈值敏感点的影响。其边界在于慢路径会更慢且 noinline 很关键,但由于扩容本就要搬移元素,额外一次调用的代价通常可接受。

收录依据很明确:文章给出了汇编、shrink-wrap 诊断和编译时统计,证明问题出在快慢路径合流导致的寄存器溢出,而非简单的代码风格差异。适合做 C++ 标准库、LLVM/编译器后端和性能优化的参考,尤其对需要理解尾调用、内联与寄存器分配权衡的读者可迁移价值很高。

技术文章Fzakaria Blog

Hijacking ELF entry points for NixOS compatibility or WTF is wrap-buddy?

这篇文章深入讲解了 wrap-buddy 如何通过篡改 ELF 入口点、动态段和辅助向量,绕过 NixOS 上预编译二进制因动态链接器路径不兼容而无法运行的问题。作者先用一个最小 C 程序演示 patchelf/autoPatchelf 在特殊 ELF 布局下的失败场景,再逐步拆解 wrap-buddy 的做法:保存原始入口指令、清空 PT_INTERP、注入自定义 RUNPATH,并在内存中恢复原样后把控制权交给 NixOS 的动态加载器。文章的核心结论是:这种方案并不是通用替代品,而是面向“常规修补失效”的病理场景,为旧二进制兼容性提供了一条极低层但有效的路径。

推荐收录,因为它不是简单介绍 Nix 工具链,而是把 ELF 启动、动态链接与启动劫持的机制讲得非常透彻,适合长期作为系统底层兼容性问题的参考。读者可以迁移的不只是某个工具的用法,更是“当静态修补失败时,如何从进程启动链路下手”的分析方法。

技术文章LWN.net

[$] Free-threaded Python: past, present, and future

这篇文章围绕 Python 的 free-threaded 版本展开,系统回顾了移除 GIL 的动机、相关历史、当前实现状态以及它对 Python 运行时和生态的影响。文章不仅解释了为什么要推进无 GIL,还讨论了这一变化在并行执行、兼容性、扩展模块支持和后续演进上的现实边界,因此适合作为理解 CPython 运行时演化的重要参考。

推荐收录,因为它提供了对 Python 核心运行时演进的结构化梳理,而不是停留在“去掉 GIL”这一结论层面。对于关注解释器实现、并发模型、C 扩展兼容性和语言未来方向的读者,这篇内容有较强的长期参考价值。

工程实践Jane Street Tech Blog

Using OxCaml to implement type-safe reference counting between OCaml and Python

这篇文章讨论了 Jane Street 如何利用 OxCaml,在 OCaml 与 Python 之间实现类型安全的引用计数与对象共享机制。文章聚焦跨语言互操作中的内存管理、所有权和生命周期约束,核心价值在于把“容易出错的运行时协议”提升为可由类型系统约束的工程方案。它特别适合关注多语言系统、FFI 设计、运行时安全和高可靠工程实践的读者。

推荐收录,因为它不是泛泛介绍 OCaml 或 Python,而是围绕跨语言内存管理这一高风险工程问题给出可复用的方法。文章的价值在于展示如何借助类型系统降低引用计数和对象互操作中的错误概率,对做 FFI、运行时或系统语言工程的人都有参考意义。

技术文章Max Bernstein

A survey of inlining heuristics

这篇文章系统梳理了动态语言 JIT 和多种编译器中的内联启发式,重点讨论“何时内联”比“如何内联”更难。作者从代码体积、编译时延迟、缓存压力、递归、调用深度、调用频率、调用上下文和 profile 传播等维度,比较了 Cinder、PyPy、V8、JavaScriptCore、SpiderMonkey、HotSpot、.NET、Dart、ART、HHVM 等实现差异,并补充了机器学习、部分内联和 AOT 信息辅助等研究方向。文章的结论是:内联本质上是一个全局收益与局部预算之间的权衡问题,启发式设计必须结合目标运行时、可观测性和分层编译策略。

推荐收录,因为它不是泛泛而谈“内联能提速”,而是把多个真实编译器/JIT 的决策规则、预算约束和调用上下文处理方式放在一起比较,长期参考价值很高。对做编译器、语言运行时或性能优化的读者来说,这篇文章能直接提供可迁移的启发式设计框架和调参视角。

技术文章Max Bernstein

Partial static single information form

文章围绕编译器中的 static single information form(SSI)展开,重点讨论“partial SSI”这一更轻量的实现路径:不必完整实现复杂的 into-SSI / out-of-SSI 算法,而是可以在 SSA 构建阶段、或借助优化阶段已有的支配式重写机制,逐步插入和消除类型细化节点。作者用动态语言 JIT 的例子说明如何根据分支条件、guard 和对象形态推导更精确的类型信息,并进一步利用这些信息消除冗余操作、提升优化效果。

推荐收录,因为它不是泛泛介绍 SSA/SSI,而是把抽象的中间表示理论落到可实现的编译器工程路径上,清楚说明了如何以较低复杂度获得可用的类型细化能力。文章还讨论了适用边界、与完整 SSI 的差异以及 JIT/动态语言场景中的实现权衡,对编译器和运行时开发者都有长期参考价值。

技术文章Eli Bendersky

Thoughts on WebAssembly as a stack machine

文章围绕“WebAssembly 是否算堆栈机”展开,作者认为这更多是术语争论:WASM 虽然主要通过栈完成运算,但同时提供了 locals,使其不像纯粹只能靠栈交换操作(如 dup、swap)的语言那样受限。作者用 Forth 中依赖大量 tuck/swap 的写法作对比,说明在复杂数据流下,WASM 通过命名局部变量能显著提升可读性。接着给出一个 add_to_byte 示例,比较折叠写法与线性写法,强调栈只是中间执行模型,程序员无需手工管理所有压栈出栈顺序。文章进一步通过 wasmtime 生成的 x86-64 代码说明,编译器会把重复读取同一 local 优化掉,最终代码与手写 C/汇编几乎一致。作者最后指出,WASM 对 locals 的不可别名性质让重复加载消除更容易成立,但这些结论仍依赖于没有对同一 local 的中途写入这一前提。

推荐收录,因为文章直接给出了 WASM 栈语义、locals 设计和编译后机器码的对应关系,并用真实反汇编证明了“多次读取 local 不会带来性能损失”。适合关注编程语言实现、虚拟机设计和编译优化的读者,具有较强的可迁移分析价值。

技术文章Max Bernstein

Value numbering

本文系统讲解了编译器中的 value numbering:先从 SSA 中“同形表达式是否可复用”的问题切入,说明它如何用于公共子表达式消除,并区分纯操作与带副作用操作。作者给出局部 value numbering 的实现思路:用哈希表为指令建立值号,遇到已存在的等价指令就用 union-find/Assign 形式替换,从而在单个基本块内消除重复计算。随后文章把问题推进到全局 value numbering,重点解释了为何必须借助支配关系而不是简单按块遍历,以及在分支、汇合和循环中 phi 节点为何需要特殊处理。文章还讨论了内存相关指令的失效与转发,例如 Load/Store forwarding、跨块的 kill set 管理,并对 Maxine、ART、V8、HotSpot 等实现做了对照。最后作者补充了统一哈希表、value partitioning、scoped hash map、JIT 场景中的强度削弱等相关方向,指出该方法对重复纯表达式很有效,但处理副作用和循环时需要额外的可用性与失效管理。

推荐收录:文章明确覆盖了 value numbering、SSA、dominators、phi 处理、内存失效与 load/store forwarding 等关键机制,并给出 Maxine 等真实实现片段作为直接证据。适合编译器、JIT 和程序优化读者参考,迁移价值在于可直接借鉴其“哈希表+支配关系+失效管理”的分析框架;主要边界是它对复杂内存建模与循环优化仍是概述性质。

技术文章Go Blog

Allocating on the Stack

文章系统介绍 Go 编译器在切片分配上的栈化优化演进:从原先 append 扩容时频繁产生 1、2、4… 的堆分配和 GC 压力,到 Go 1.25 对小尺寸 make([]T,0,n) 的推测性栈分配,再到 Go 1.26 对 append 扩容场景也能先用栈上小缓冲、必要时再转堆。作者解释了返回切片等逃逸场景下,编译器如何借助 runtime.move2heap 把最终结果搬到堆上,同时尽量保留中间阶段的栈分配收益。文章还点明这些优化依赖切片最终大小、是否逃逸以及 32 字节等边界条件,并给出关闭优化的调试开关。整体上它展示了 Go 通过编译器与运行时协同减少分配、降低 GC 负担的具体机制与适用边界。

推荐收录,因为文章直接给出了 Go 1.25/1.26 在切片分配上从堆到栈、再到自动回迁堆的实现路径,属于可长期参考的编译器优化案例。适合关注 Go 性能、编译器和运行时协同的读者,也能帮助工程师判断哪些写法会触发或错过这些优化。

技术文章Max Bernstein

Type-based alias analysis in the Toy Optimizer

文章延续 Toy Optimizer 系列,围绕加载/存储转发中的别名分析展开,先指出仅按偏移量划分 alias class 太粗,会把不同类型对象上同一偏移的访问误判为冲突。作者借鉴 type-based alias analysis,用类型层次树的前序/后序区间表示各 heap region,将“是否可能别名”转化为区间重叠查询,并在缺少类型信息时退化到 Any。随后又补充了对象来源、分配点、常量对象和已知内建函数副作用等更强的别名线索,用于局部保留或部分失效缓存的 heap 信息。文章还讨论了未知调用、逃逸对象与保守失效的边界,强调这种做法在 JIT 和受控语言中能以较低成本提升优化精度,但在通用 C-like 场景下需要更强的分析配合。

推荐收录,因为文章给出了从偏移量别名到类型层次 TBAA 的具体改造路径,还展示了与对象来源、内建副作用和未知调用的联动处理。适合做编译器、JIT 和语言运行时优化的参考,尤其对需要在精度与分析成本之间取舍的读者很有迁移价值。

工程实践Go Blog

The Green Tea Garbage Collector

文章介绍 Go 1.25 中实验性垃圾收集器 Green Tea 的设计与落地。作者先回顾 Go 现有的标记-清扫 GC,指出其主要成本集中在标记阶段,而且大量时间浪费在指针追踪带来的随机内存访问和 CPU 缓存失配上。Green Tea 的核心改动是“按页而不是按对象”组织工作队列:在页级别积累待扫描对象,用 seen/scanned 位图在页内区分已发现和已扫描的对象,从而把零散遍历变成更连续的内存扫描。文章进一步说明它如何借助 AVX-512 和 VGF2P8AFFINEQB 等指令做位图扩展与筛选,把多个步骤压缩到寄存器内完成。实测显示,多数负载可减少约 10% 的 GC CPU 时间,部分负载可达 40%,但结构很不规则、每页常只出现单个待扫对象的场景收益会变小甚至可能回退,因此仍是一个依赖工作负载形态的优化。

推荐收录,因为文章给出了 Go 运行时 GC 的具体瓶颈、页级扫描的新算法、位图与向量化实现细节,以及在生产环境中的量化收益,证据充分且可迁移性强。适合关注运行时、性能优化、缓存友好数据布局和指令级加速的读者;同时也提醒读者该方案对负载形态敏感,实验性开关阶段仍需做基准验证。

工具笔记Go Blog

Flight Recorder in Go 1.25

文章介绍了 Go 1.25 新增的 flight recorder:它基于执行 trace,但不再把全量数据写到文件或 socket,而是将最近几秒的 trace 缓存在内存中,等程序检测到故障时再一次性导出。作者给出 `MinAge`、`MaxBytes`、`Start/Stop` 与 `WriteTo` 的使用方式,并说明该机制特别适合长时间运行的 Web 服务。文中以一个 HTTP “猜数字”服务为例,展示如何在请求耗时超过 100ms 时触发快照,再用 `go tool trace` 查看时间线和 flow event。最终定位到 `sendReport` 中 `defer Unlock` 让锁持有时间被意外拉长,导致偶发长尾延迟。文章也明确了适用边界:它不是全量追踪方案,仍需合理控制内存预算和触发条件。

文中直接给出 flight recorder 的 API、配置参数、快照导出和 trace 分析流程,并用真实并发性能问题证明其定位价值。适合维护 Go 长运行服务、排查线上延迟和锁竞争的工程师,迁移价值在于“先留最近窗口、再按异常触发取证”的诊断思路。

工程实践Datadog Engineering

How we tracked down a Go 1.24 memory regression across hundreds of pods

这篇文章复盘了 Datadog 在大规模将服务升级到 Go 1.24 后,如何在数百个 Pod 中发现并定位一次内存回归。作者先通过系统级指标和线上观测确认问题不是单点实例异常,而是与新版本运行时相关的整体性内存上升。随后他们逐步缩小排查范围,最终把根因指向 Go runtime 的分配器缺陷,并与 Go 团队协作推动修复。文章的价值在于展示了从真实生产信号、跨层指标关联到运行时 bug 定位的完整排障链路,但其结论也明确依赖于特定 Go 版本与运行时实现环境。

推荐收录,因为它直接给出了“Go 1.24 内存回归—系统指标定位—runtime 分配器 bug”这一完整证据链,而不是泛泛讲升级经验。适合做生产排障、性能回归分析和运行时问题定位的参考,尤其对大规模 Go 服务团队具有可迁移的方法价值。

工程实践Datadog Engineering

How Go 1.24’s Swiss Tables saved us hundreds of gigabytes

文章介绍 Datadog 在 Go 1.24 引入 Swiss Tables 后,对内部高流量服务中的 map 内存占用和性能收益做的实测复盘。作者说明旧版 Go map 在某些业务场景下会带来较高的内存开销,而新实现通过更紧凑的布局和更高效的查找方式,能在 map 密集型工作负载中把内存使用降低最高约 70%。文中重点不是泛泛宣传新版本,而是展示他们如何用 profiling 和线上指标确认收益、识别适用场景,并把改动控制在可验证的范围内。文章也暗示这类收益依赖键值分布、访问模式和业务负载,并非所有程序都会得到同等改善。

推荐收录,因为它给出了明确的工程证据:围绕 Go 1.24 Swiss Tables 的真实工作负载剖析、内存节省幅度和性能验证,而不是停留在版本公告。适合关心 Go 运行时、服务内存优化和性能排障的工程师参考,尤其适合把“新 runtime 特性是否值得升级”转化为可测量、可回滚的决策流程。

技术文章fasterthanli.me

Catching up with async Rust

文章围绕 Rust 中 async fn in traits 的稳定化,回顾了 free function 和 impl 方法里的 async 早已成熟,但 trait 里长期缺位所造成的生态断层。作者解释了这一特性背后的关键难点,包括异步函数返回值难以直接命名、trait object 的对象安全限制,以及编译器如何把 async 代码降解为状态机。文章还对比了过去常见的 async_trait 宏方案与原生语法的差异,指出原生支持能减少样板代码、提升可读性,但并没有彻底消除 dyn 兼容、泛型边界和性能理解上的复杂性。整体上,它更像是一篇帮助读者跟上 async Rust 现状与迁移边界的技术梳理,而不是入门教程。

收录,因为文章直接围绕 async fn in traits 的稳定化展开,并明确讨论了状态机降解、对象安全和宏替代方案等关键技术证据,而非单纯功能播报。适合已在使用 Rust async 的读者,以及需要判断新特性迁移边界、理解原生语法与 async_trait 差异的工程场景。

工程实践Datadog Engineering

How we built a Ruby library that saves 50% in testing time

文章介绍 Datadog 用 Ruby 实现测试影响分析库的过程,目标是在代码改动后只运行真正受影响的测试,从而缩短 CI 时间。作者先梳理 Ruby VM 中方法调用、对象分配和加载行为,借助 tracing 记录代码间依赖,再把生产代码与测试用例建立映射。文章详细讨论了 Ruby 动态特性、monkey patch、反射和框架层封装带来的分析误差,以及如何通过过滤规则和采样降低开销。最终该方案在内部场景把测试耗时减少约 50%,但对强动态、依赖隐式副作用的项目效果会下降。全文属于真实工程经验,适合需要优化 CI、构建测试选择或理解 Ruby 运行时可观测性的读者。

收录,因为文章直接给出了“受影响测试选择”这一工程问题的实现路径,且用 Ruby VM tracing、依赖映射和约 50% 的测试时间下降作为明确证据。适合做 CI 优化、测试基础设施或运行时可观测性的读者;同时也提醒动态特性强的代码库会带来准确率风险。

工程实践Datadog Engineering

.NET Continuous Profiler: Exception and lock contention

文章讲解 Datadog 在 .NET 连续性能分析器中,如何识别并处理异常与锁竞争这两类对性能影响很大的运行时事件。作者先说明连续采样式 profiler 的约束:既要尽量低开销,又要在高频事件下保留足够语义,因此不能简单依赖传统的堆栈采样。随后分别讨论异常与锁竞争的采集思路、事件归因方式,以及如何把运行时信号映射成可分析的性能数据,同时避免对应用造成过多扰动。文中也强调这些机制依赖 .NET 运行时能力与事件可见性,适用于需要在线观测异常风暴、锁争用和尾延迟问题的场景,但对非 .NET 平台的直接迁移有限。整体来看,它提供的是一篇围绕真实产品实现的 observability 工程经验,而不是泛泛介绍 profiler 概念。

推荐收录,因为文章直接围绕连续 profiler 的实现细节展开,明确讨论了异常与锁竞争的采集、归因和低开销约束,属于可复用的工程方法而非产品宣传。适合做 APM、性能分析、运行时观测和 .NET 工具链设计的参考,但需要注意其方案强依赖 .NET 运行时特性,跨语言迁移时要重新评估事件模型。

工程实践Datadog Engineering

.NET Continuous Profiler: CPU and wall time profiling

这篇文章介绍了 Datadog 在 .NET 连续 профiler 中实现 CPU profiling 和 wall time profiling 的方法。作者不仅说明了两类采样各自回答的问题,也分析了它们在低开销、跨线程、跨运行时边界下的实现约束。文中重点讨论了如何持续获取调用栈、如何区分真正占用 CPU 的时间与线程阻塞或等待造成的 wall time,以及这些数据如何帮助定位性能瓶颈。文章还指出,连续剖析必须在精度、性能损耗和运行时安全之间折中,因此采样间隔、信号处理和线程状态判断都会影响结果。它更适合关注性能分析、运行时观测和 profiler 设计的读者,尤其对 .NET 服务的线上诊断有参考价值,但不适合作为通用入门教程。

文中直接讲了 .NET 连续 profiler 的 CPU 与 wall time 实现细节,不是产品介绍,而是可复用的观测与采样设计经验。适合做性能诊断、运行时工具或可观测性基础设施的读者参考,尤其能借鉴其在开销、精度和线程安全之间的取舍。

工程实践Datadog Engineering

.NET Continuous Profiler: Under the hood

文章介绍 Datadog 为 .NET 设计的持续性能剖析器,目标是在生产环境中 24/7 运行且几乎不增加可感知开销。作者从底层实现出发,说明它如何借助 CLR/运行时接口采集 CPU、锁等待与堆栈等信息,并把热路径上的工作尽量压缩到采样和轻量汇聚。文中还强调数据上报、线程安全和后台处理等工程取舍,以避免 profiler 本身成为性能瓶颈。整体结论是:持续 profiler 能在大规模线上系统中提供稳定诊断能力,但必须严格控制采样频率和额外内存、同步成本。

收录理由是文章明确围绕“生产环境 24/7 运行、影响可忽略”这一目标展开,并给出实现层面的约束与取舍,而不是泛泛介绍产品功能。适合 .NET 性能优化、APM/可观测性平台和运行时工程读者参考,其可迁移价值在于低开销采样与后台汇聚思路,但细节强依赖 CLR 和具体实现边界。