久驻内存与一个对象文件系统的设想

NTL01

这个想法源于对数据流架构（dataflow architecture）的思考，直接源于正在探索的个人小项目。

今天查了之后才知道，原来久驻内存（non-volatile (main) memory, 非易失性内存）已经商业运行了。分级存储的根源是计算机诞生初期的储存介质成本问题，按单位成本总体是cpu缓存>(非久驻)内存>固态硬盘>机械硬盘，但这个设定直接影响了操作系统以及由此而来的几乎所有软件设计，造成了不必要的复杂性。

冯诺伊曼架的原理是计算单元与内存/存储单元平级，但分级存储让人们设计程序时候要考虑到“信息/数据”在非久驻存储、久驻存储的两种情况，而且两种情况都要与计算单元对接，大大增加了复杂性。更严重的是，长期以来操作系统领域的种种教条连同程序语言的一些设计问题（比如c的指针、Py的“对象”）加剧了（狭义）内存与硬盘的对立，“数据结构”严重局限在以内存对象为主，虽然xml、json等序列化工具/框架以及“对象存储”等数据库技术的发展一度冲击了这一范式，总的情况没有改变。

关于数据流架构可以参考这个，我最近两次关注这个东西，第一次是进一步了解lambda calculus时考虑程序切分，然后由于后者的理论困境而放在一边；第二次是学习对象权限模型（Object-capacity model)，意识到安全性（safety）与程序的逻辑是一个硬币的两面，更好实现对象权限特别是保留足够的灵活性（尤其是面对流数据时）需要像数据流架构似的“源于基本结构的可迭代”模型，而后者本身对流数据的优势又让前者得到保证。了解到这一层，依赖注入、负载均衡等问题就次要而且相比而言简单了很多。

数据流架构与久驻内存何种关系呢？刚才那篇文章以及wikipedia提到数据流架构通过空间换时间，I/O是一大挑战，但我昨天转念一想，要突出优点，缺点随着技术发展解决起来很可能比想象得快，而且数据流架构最大挑战并不是I/O，而是逻辑模型本身。于是我就换一个角度，从文件系统考虑数据流模型/架构，于是打开了一扇窗——主要问题是“对象化”，如果把数据、逻辑、算法（程序）当作一些孤立的元数据（人和高级程序均不可读的二进制）那通过各种接口实现调用当然非常困难，这也是相比之下冯诺伊曼架构通过种种硬件层面升级反而巩固了非对象化结构的原因，把重要数据集中到缓存里，其实是矮化了数据让更合理的程序逻辑反而难以运行。

久驻内存提供了一个融合非久驻内存中数据结构与久驻存储中数据的绝佳机会，在软件/根基设计层面，自然适合面向对象的文件模型，简言之这几十年一般意义上的“文件”要被与程序完全契合的“对象”所取代，前者的产生是分层存储带来的时代误会。

我对这个对象文件系统的初步设想是：
1 整个系统分为横纵两个维度。横向是所有程序按优先级、逻辑关系所形成的排布，可能是一个树形结构，中间、最高位置是的根，但可以展成比较对称的一维数组；纵向是每个程序所对应和可支配的对象，可以是非程序（接近所谓的（非可执行）“文件”）也可以是程序但作为非运行对象而存在（参考Flink中的SingleOutputStreamOperator作为DataStream子类的情况）。纵向的“文件”结构可类比成“按列存储”的数据库模型。

2 所有对象（包括“文件”）的引用都采用实地址（real mode）和硬件层次的垃圾回收机制。「参考3」所有对象的物理实体以分块（chunk）形式存在与单个存储介质以及虚拟（分布式）介质中「参考4」。这样从底层直接解决对象的引用效率和安全性（避免空指针）问题。程序员和使用者基本不需要考虑文件大小、序列化及由此产生的编码问题、文件格式（同一数据特别是多媒体文件不同格式一开始软件专利的副产品，后来与编码等其他复杂问题纠缠在一起）等等问题，这些都交给最上面横向排布的“程序”来解决；也不需要甚至没有“删除”/“彻底删除”/“格式化”等问题，这些全交给垃圾回收系统和对象权限为基础的安全模式，硬件漏洞基本上不存在。

这两个基本设想的原理是1 对象化与面向对象 2 接口化/抽象化、层次化、递归化，这是Lambda Calculus、函数式编程、面向对象思想及各种衍生品（比如高级语言计算机）背后的思想，我学习并继承过来用看看能不能再走得远一些。让好的设计理念不要局限在程序终止/关机即销毁的短时内存中。

基于这个设想，小项目的其他部分，比如应用流（application streaming）部分就有了可轻松依靠的基础。

那这个对象“文件”系统先完成迷你实现难度如何呢？

首先数据结构部分（比如树形结构）已经有现成的了，比如有Oberon把（所有？）文件放到B-Tree里面的先例，把硬盘里不可直接操作的文件转换成可直接操作对象（二进制->Audio对象）并附以合适的操作子（/程序）衔接和权限设定本身就是应用软件的日常，这里只不过把孤立、（因断电消失而导致的）重复工作统合到一个高层结构。

然后针对目前硬件限制、个人知识所限和小项目本身的阶段性，先实现虚拟机内的模拟即可。由于既有程序语言是针对短时内存而设计的情况，我考虑其入手点是依靠Java虚拟机的垃圾回收 a）如何保证对象被引用/不被回收和不被引用/被回收的安全、高效切换，要设计类似“回收站”的机制 b）通过序列化机制让内存运行状态可以与长期存储/序列化后形式彼此转换。b的要求基于前面的两点基本设计应该比无此设计的“进程迁移”要容易。

如果大家有对实现这个小系统的好想法请告诉我！如果知道这个系统根本不可行更要告诉我！！

参考：
1 非易失性内存在阿里生产环境的应用：Tair NVM实践总结 https://zhuanlan.zhihu.com/p/41356902 / https://yq.aliyun.com/articles/622726
2 vSphere 支持 Intel 傲腾内存： https://blogs.vmware.com/china/2019/04/10/vsphere-%E6%94%AF%E6%8C%81-intel-%E5%82%B2%E8%85%BE%E5%86%85%E5%AD%98/
3 https://en.wikipedia.org/wiki/Object_storage
NOVA: A Log-structured File System for Hybrid Volatile/Non-volatile MainMemories: http://cseweb.ucsd.edu/~swanson/papers/FAST2016NOVA.pdf
4 Thoughts on Computer Architecture: http://csg.csail.mit.edu/Users/dennis/barc-presentation/index.htm4
5 一种新的操作系统设计

NTL01

今天才知道有个已经成熟运用的设计模式：Infrastructure as code

其中的代表包括Terraform，它用Go写成，我猜很可能跟容器工具一样主要是通过一些操作系统基本功能比如文件权限实现中间件功能，但比Docker、Kubernetes更进一步。

从整合管理角度看，IaC的思想与我这个文件系统设想有很强的内在一致性：
执行计划：Loader和Linker的发展，让“程序矩阵”的控制更全面、细致。
资源拓扑图（Resource Graph）：所有程序、状态、对象-文件都是资源，从横纵向“原点”开始boot，然后管理全局。
Terraform中状态管理有特殊设计，这也是我惊喜但又意料之中的。

参考
Terraform 是什么 http://www.andrew-programming.com/2020/07/01/terraform-%e6%98%af%e4%bb%80%e4%b9%88/
http://www.andrew-programming.com/2020/07/01/terraform-%e7%9a%84%e5%87%a0%e4%b8%aa%e5%85%b3%e9%94%ae%e6%a6%82%e5%bf%b5/

NTL01

经过STEP的分析之后发现，STEP模型与Java Beans异曲同工。过程挺有趣的，STEP里有类型推导的思想，不只等同关系还有非等同关系（比如线+曲面->曲面线），今天突然发现Jackson/Gson有非常类似过程，就是把object用反射打开之后一顿找，然后根据定义好的规则推出来结果，再稍微了解之后意识到这就是Beans的思路，也是当年被归入SQL的东西，比如join之后再产生出新变量，只不过后来SQL僵化了，实际上它抽象的不仅是储存形态还包括符号关系。

不知道别的语言生态系统中有没有这种东西，我猜JS系统是有的，因为JSON这东西其实跟DXF、IFC、STP等等东西本质都是一样的，就是打好标签（跟类-Entity对应）+标签可以层次化（继承关系），XML是90年代诸多方案中的一个只不过后来胜出，人们误以为都是从XML继承来的。

这种数据模型学名叫“对象关系映射”。说白了就是如无必要误增类型，所谓的“类型”是一个对象中的属性，相当把高维空间降到2维——（类型，实例）一对应，而不是n个类型每个都有很多实例。这种思想据说是在SQL里得到了实现，要我说，就是层次化构建数据，先定义原始类型，然后原始类型组成自定义类型，自定义类型互相还可以包含或排斥（注意对逻辑操作的支持）。

了解到这一步，几十年人们的探索成果其实很简单但久经考验，对于久驻内存和对象文件系统是什么启发呢？

首先，不需要额外数据模型，还是通用的那些，这点推翻了我之前的猜测。
然后，能做的主要是数据模型的实现上，一方面不需要反复序列化和反序列化了，工作少了，另一方面实现更细粒度的操作。

看计算机先驱像Wilkes、Wirth他们的东西，这种思路已经想到了，就是递归。他们强调怎么储存和处理是一回事儿，关注的重点应该是结构化本身：你再神奇高效的数据结构也得以不超过二维形式表示，然后达到和线性数据结构的对应。

NTL01

今天才了解到Oberon后续——Oberon2和3的情况，其中实现和超越我的设想部分包括：

临时（transient）对象和久驻（persistent）对象互相调用
整个系统层面的垃圾回收，方法是分析引用，跟早期垃圾回收算法一样
纲要演化（schema evolution），（具体方法有待了解—涉及信息模型、状态管理、网络等问题）
实现对象共享的Carrier/Rider模式
临时对象与久驻对象的映射，（具体方法有待了解）

此外还有Active Object，把对象作为“过程”（process）而不是一些“面向对象”系统“一切皆对象”把过程/进程/线程也视作对象。其实这个做法在“函数式警察”们所批判的SmallTalk（80年代）中就出现了，曾给我启发，但加上后来出现的信息建模中都坚持对象过程二分，一度认为不可行，现在看有时候流行的未必是最合理的。