应用流技术的关键是如何让本机没有的程序在输入后运行，比如A程序位于主机甲，其中的一个模块m要放到主机乙上运行。
这是看起来比RMI、消息传递更复杂的事情，无法用对象序列化的手段实现「今天群里讨论此事，感谢大家的建议」。
了解到这一技术让我非常欣喜，理由如下：
1 找到了一种实现应用流、子程序移植后运行的高效方法，同时也是安全方法，避免了程序打包造成的孤立化问题，这是一种程序数据结构化的方案，可以与对象权限模式对接而避免了反射造成的安全性问题。改技术的原生支持在java.lang.Instrument与reflection是完全不同的。
2 程序能实现运行中动态修改字节码从而调整自己的行为，是冯诺依曼架构的体现和良好应用。冯诺依曼架构的主要特点之一是对程序和数据在储存层面上的同一化，相比之下有的架构方案讲二者在储存层面视为本质不同对象。这在字节码修改技术中体现为：程序依靠自身的一部分形成运行时环境（“程序”），在此环境内修改未被调用的部分（“数据”）。程序-数据可以方便互相转化是冯诺依曼架构的优点。
3 该技术与数据流架构可以兼容，数据可以作为引用方向（“指针”）激发程序运行，激发节点运行后又可以以数据形式保留，大大减少了空间占用并实现了逻辑优化。
整个流处理软件从运行逻辑看可以由4-8个功能子（functor）组成，他们是处理器中寄存器的抽象化，假设一个程序要经历 A->B->C->D E->F D,F->G 的变化，可以先让A->B->C->D用一两个功能子完成，A到B完成后A被动态地修改成C，然后B指向C（原来的A），直到D； 同时D到F由另一到两个功能子完成；再往后需要一到两个功能子实现D和F一起到G的处理。
以上运行过程的结果可以从保留A到G全部、保留若干甚至G被利用或一段时间后丢弃不保留的多种可能，由“状态管理层”实现。之所以不叫模块，是因为状态管理也是由这些功能子实现的，它们被动态地赋予“状态管理”功能，又不时变成“状态实现”/“运行逻辑”/“纯计算”模块，然后再去做状态管理。
相当于一个公司有多个部门，但员工数量很少，大多员工都是身兼数职的，老板起到总体协调和守夜人/自启动模块的作用。
[ps 把状态管理甚至对象-文件管理做成单独模块会不会更高效，因为字节码修改也费很多时间？这个目前还不清楚，要探索甚至长期探索，有一种可能是软件层面的“超线程”(hyper-threading)优化，当然这需要借助高级的编译器原理。]
实际上，字节码修改技术更反趁了分层存储的不合理：源文件编译成字节码是必要的，字节码被加载到（非久驻）内存中是从计算机架构角度看不必要的，因为“加载”只是形成一个运行时环境，而这个环境还是用虚地址充满分割的虚拟化环境，如果将内存与外存合二为一，字节码文件不需要被加载只需要被按需以实地址读取即可，读取后形成一些临时对象（“文件”）对应“内存”，后者的取舍由程序及用户决定。
在实地址、同质久驻存储的条件下，编译器和解释器都以“操作系统”层次直接安装在硬件上，操作系统以及docker之类的东西都被大大简化甚至划入“程序联合体”。
到目前位置，理论学习与研究初步解决了这个小工具的自身数据架构、运行时环境（及迁移）、程序逻辑三大关键问题，上层的框架已经形成，接下来要学习并实践这三部分的代码实现，并向下探索像网络协议之类的问题。
参考：
1 https://www.infoq.com/articles/Living-Matrix-Bytecode-Manipulation/
2 https://tech.meituan.com/2019/09/05/java-bytecode-enhancement.html
3 https://blog.souche.com/javazi-jie-ma-cao-zong-chu-tan/
4 Toward the Computer Utility: A Career in Computer System Architecture: http://csg.csail.mit.edu/Users/dennis/essay.htm
5 一种新的操作系统设计