池化服务器压缩¶

在授权实例之间共享编码后的冷内容，同时让每个客户端掌控恢复。只有共享存储与编码工作节省的成本超过协调和服务开销时，池化才值得采用。

目标与现状¶

目标设计让客户端持有自己的不可变内容句柄，并在本地解码。这不是当前 macOS/HVF 实验性堆冷池的能力：其服务在堆中保留 payload，服务丢失可能导致依赖它的 VM 失败。Linux sealed memfd 交付仍是提案； macOS 尚未交付等价 sealed backing。

服务器可以索引内容、编码、协调发布、管理预算并缓存共享对象，但不拥有 guest 地址或机器快照。每个实例按环境快照合同独立负责 checkpoint 保存、压缩和恢复。

VM 捕获稳定冷内容，服务器生成或复用不可变编码对象。客户端校验并持有自己的句柄后，运行时才能回收 RAM。 backing 承载字节，codec 压缩字节；memfd 不会自动压缩或去重。

CPU 访问或设备准备时，客户端本地解码，恢复私有可写页。共享编码字节不能把独立实例的可写 RAM 连接起来。交付后，服务器退出只影响新发布，不影响已持有内容的访问；交付前失败则保留原 RAM。这些仍是拟议保证。

相比实例内压缩，池化可以避免重复 payload 和重复编码。去重仍是可选策略，且限于授权信任域；内容身份不等于授权。

池化增加 IPC、排队、竞争、元数据和共同运维成本。客户端持有对象缩小了可用性边界，但内容损坏或恢复失败仍需停止受影响的 runner，不能用零页或旧 checkpoint 字节替代。运行态对象不提供宿主崩溃后的持久性。

计入服务器内存、共享对象实占和客户端 RAM。预留临时副本与解码余量，让恢复优先于后台工作；同时评估 CPU 成本、业务尾延迟和压缩节省。

先在不回收 RAM 的情况下证明不可变交付和服务退出后恢复。再验证 Linux pager 与 CPU/设备映射接入，之后才启用破坏性回收。昂贵的编码和发布留在冻结窗口外；两阶段发布提供机制经验，但不能证明恢复竞争已经解决。

保留冷池与整 VM offload/FUSE backing的现有不兼容约束，且不在同一 RAM 区域叠加 KSM 与冷压缩。

内存证据尚未建立已知的生产净收益，也未验证净物理内存节省。旧池结果不能验证客户端持有 backing 的方案。架构索引与压缩概览保留这些能力边界。