定档：CPU tensor.data 由 shm 直管（方案1）还是 @ 引用+extstore 后端（方案2）——deepx-cpu-kvspace-extstore 存废

[miaobyte]

背景

CPU tensor 的 data 缓冲区放在哪、由谁管理，需要一次定档。这直接决定独立仓 array2d/deepx-cpu-kvspace-extstore（原 deepx-heapmem-cpu）是否有存在必要。

参见架构分层：kvspace 分元存（slot + 索引，存 shape/dtype/引用）与扩展存储（大 value / tensor data 实体）两层；kindexpr @ 前缀标记「扩展世界句柄」——真实 xvalue 不在元存，元存只留一条元信息，实体读写走扩展存储。

两个选择

方案 1：tensor.data 直接由 kvspace-c 的 shm 管理

CPU 上的 tensor 实体数据就是 kvspace 共享内存里的一段 raw bytes，shm_set_raw / read_tlv 直接读写，kvlang 直接向 kvspace 申请一块 tensor data。

• 现状：已默认支持。kvlang 可直接向 kvspace 申请 tensor 的 data，无需外部执行器介入。
• 含义：CPU 场景下 kvspace 本体即扩展存储，没有独立的 extstore 进程/库。

方案 2：tensor.data 作为 @ 引用路径，由 deepx-cpu-kvspace-extstore 管理

元存里只放一个 @ 句柄（extindex / extpath 已有原型），tensor 实体由独立后端 deepx-cpu-kvspace-extstore 分配与管理其生命周期。

• 含义：CPU 与 GPU（显存）走同一套 extstore 契约——元存存 @ 引用，实体在扩展世界，后端负责生命周期。
• 代价：多一个进程/库、多一跳；CPU 上 shm 本已是共享内存，额外间接层的收益需论证。

待决问题

方案 1 已经跑通并默认可用。问题是方案 2 是否还有存在必要：

• CPU 场景下，把 tensor.data 从 shm 内联改为 @ 引用 + 独立后端，能带来什么 shm 直管拿不到的能力？（跨进程共享？生命周期/引用计数？与 GPU 后端的接口统一？）
• 若唯一价值是「与 GPU extstore 接口对齐」，能否让 CPU 直接复用 shm 作为 extstore 的一种后端实现，而非另起一个 deepx-cpu-kvspace-extstore 仓？
• 若方案 2 无独立价值，deepx-cpu-kvspace-extstore 应归档/删除。

决策产出

结论应明确二选一，并据此决定 deepx-cpu-kvspace-extstore 的存留。

[miaobyte]

方案 2 的意义：shm 尚缺动态扩缩容

方案 1（shm 直管）目前的硬约束是：shm 容量在创建时锁死，运行期无扩缩容路径（详见 #15）。data_size 在 kvspaceShmOpen 创建时一次 ftruncate + mmap 定死，之后只能沿用。

tensor data 体量动态、可达 GB 级，固定容量的 shm 要么写满即失败，要么被迫按峰值超额预分配。方案 2 把 tensor.data 作为 @ 引用交给独立 extstore 后端管理，正是为了绕开这个约束——后端可按需分配、独立管理生命周期，不受单块固定 shm 容量限制。

不过这只是当前实现的局限，相信后期可解决（#15 已提出 mremap 扩容 / PUNCH_HOLE 缩容 / offset-based 引用保证重映射地址稳定等方向）。

一旦 #15 落地，shm 本身即可动态扩缩，方案 1 就能覆盖方案 2 目前的主要动机。届时再回来判定：extstore 后端是否还有 shm 直管拿不到的独立价值（跨进程引用计数、与 GPU 显存后端接口统一等），据此定 deepx-cpu-kvspace-extstore 存废。

结论：本 issue 暂挂，阻塞于 #15。