Chill Magic’s Blog

【CVM】【2018.3.22】CVM 的内存占用优化（二）

2018-03-22T00:00:00+08:00

优化前后内存占用的对比

在上一篇【CVM】【2018.3.16】CVM 的内存占用优化（一）中，对 CVM 进行了两次优化，这篇将继续进行。

优化前	优化（一）后	优化（二）后
80.9 MB	23.2 MB	9.4 MB

本文主要是对 parser 的优化。

优化1 ：面向对象的 Instruction 基类添加 virtual 析构

单纯分析 parser ，让 ParseInfo 结构体析构。将相应的组件进行析构。其中，using InstList = std::vector<Instruction*>>; 在析构 FunctionInfo 时，将 InstList 所有指针删除。

构造前	析构前	析构后
0.3 MB	7.1 MB	4.4 MB

发现， ParseInfo 并没有完全析构。

根据 VS 2017 的调试工具，发现析构后有许多 Inst 相关的内存没有被释放。随后发现， Instruction 基类并没有 virtual 析构函数。

加上后，测得：

构造前	析构前	析构后
0.4 MB	7.8 MB	0.6 MB

可以发现，大部分的 parser 析构成功。

优化2 ：重构 parser

将 FunctionInfo 这种公用部分提取出来，直接共享使用（std::shared_ptr）
使用 index (size_t) 代替直接使用函数名 (std::string)

FunctionInfo 从 parser 开始，直到 runtime 都在使用。频繁地转换不仅会增加内存占用率（没有及时释放），还会降低效率。

因为 FunctionInfo 生成后是不改变的，在生成过程中会使用 std::vector 这种可变数组，生成后使用一段内存（PriLib::lightlist），遂增加 FunctionInfoCreater ，在生成两个 FunctionInfo 之间会清空状态，这样可以减小内存占用。

Time	备注	占用内存
第一次 pause	parser	7.7 MB
第二次 pause	parser + compiler	15.1 MB
第三次 pause	parser + compiler + runtime	16.3 MB

优化3 ：提前析构 parser

优化1 使得析构 parser 可以获得减少大量内存占用，优化2 重构 parser 后，提前析构 parser 。

结果如下：

Time	备注	占用内存
第一次 pause	parser	7.8 MB
第二次 pause	compiler	8.2 MB
第三次 pause	compiler + runtime	9.4 MB

【CVM】【2018.3.16】CVM 的内存占用优化（一）

2018-03-16T00:00:00+08:00

优化前后内存占用的对比

commit

优化前	优化后
80.9 MB	23.2 MB

测试样例

;; test.cms

.program
    .entry main

.func Math#add
    .stvarb 2, cms#int64
    .arg 2
    call %res, cms#int64#+, %1 %2
    ret


.func main
    .stvarb 2, cms#int64
    .stvarb 1, cms#int64
    load %1, 5, cms#int64
    load %2, 6, cms#int64
    call %3, Math#add, %1 %2 ;; 40000 个
    ret
    

文件总共 1.14 MB 。

在程序执行前、执行后各插入一个 system("pause"); 记录其时的内存占用。

优化前结果

使用 Visual Studio 2017 的 x64 Release 模式编译，在 Windows 10 下运行结果：

Time	备注	占用内存
第一次 pause	parser + compiler	41.6 MB
第二次 pause	parser + compiler + runtime	80.9 MB

结果分析

parser + compiler 部分占用了 41.6 MB
runtime 部分占用了 39.3 MB

理论上，由于全局使用静态寄存器，在 Math#add 函数调用结束后应该能够销毁。而使用性能探查器进行测试时发现，内存占用只增不减。所以应该是内存泄漏无误。

所以先对 runtime 部分进行优化。

第一次优化（对 runtime 进行优化）

首先观察是哪个地方出现的泄漏。

Math#add 函数被调用了 40000 次，而它调用了 cms#int64#+ 函数。cms#int64#+ 函数是内嵌的，它使用的寄存器都是静态的，理论上不存在分配问题。

因此将 Math#add 换成 cms#int64#+ 进行测试。

测试结果如下：

Time	备注	占用内存
第一次 pause	parser + compiler	41.5 MB
第二次 pause	parser + compiler + runtime	41.5 MB

可见在进行指令函数的调用时，会产生大量的内存泄漏。

理论上，对 cms#int64#+ 进行调用不应该占用内存。而实际测试发现，确实没有可见的内存占用。因此对内置函数的调用运行状况良好。

下面对指令函数的调用进行分析。

指令函数调用时会自动创建一个 LocalEnvironment 。

创建使用 new LocalEnvironment ，并加入到 _subenv_set 中，同时执行 Call 。

_subenv_set 存储的是 std::shared_ptr<Environment> ，当该环境不被使用，移除节点，即可销毁环境。

但是并没有在结束时并没有将节点移除，因此存在非常严重的泄漏问题。

在 Call 指令加入节点后、调用子环境后，移除该节点，即可解决这个泄漏问题。

结果如下：

Time	备注	占用内存
第一次 pause	parser + compiler	41.7 MB
第二次 pause	parser + compiler + runtime	43.0 MB

优化后，runtime 的内存占用从 39.3 MB 降到了 1.3 MB 。成果显著。

第二次优化（对 compiler 的优化）

现在，将 parser 与 compiler 之间插入一个新的 pause 进行测试：

Time	备注	占用内存
第一次 pause	parser	8.4 MB
第二次 pause	parser + compiler	41.7 MB
第三次 pause	parser + compiler + runtime	42.8 MB

占用：

parser 8.4 MB
compiler 33.3 MB
runtime 1.1 MB

因为 compiler 占用了相当大的部分，所以先对此进行优化。

compiler 会编译生成大量的 lambda 。

call 指令包含一个 dst 和一组 src 。

在目前的版本中，会生成一个能够获取 DstData 的 lambda 和一个获取 SrcData 组的 lambda 。在 x64 下，对这两个进行 sizeof ，分别是 64 字节和 24 字节。

将 call 的 lambda 对外部变量的拷贝改成引用后，compiler 占用内存由 33.3 MB 变为了 4.9 MB 。（但是会无法运行。）

将获取参数列表与返回参数的两个保存了 lambda 的 std::function 改为结构体后，内存占用变为了 19.2 MB 。再将获取 call 所调用的函数由 lambda 变为在本体 lambda 内执行，内存占用变为了 13.5 MB 。

可以看出，目前编译为 lambda 的形式会造成内存占用过大的问题。因为修改这种形式需要大幅度修改，目前暂时只修改 call 相关的编译代码。

结果如下：

Time	备注	占用内存
第一次 pause	parser	8.4 MB
第二次 pause	parser + compiler	21.9 MB
第三次 pause	parser + compiler + runtime	23.2 MB

总结

本次优化，内存占用从最初的 80.9 MB 优化到了 23.2 MB 。共优化 57.7 MB 。

发现了 runtime 期间调用指令函数时创建 LocalEnvironment 时的内存泄漏问题。修复后优化了 38.0 MB 。
发现了直接编译为 lambda 内存过大的问题。由于改动幅度较大，准备重构 compiler 部分。目前的临时优化，优化了 19.6 MB 。

下一篇优化记录，将会在重构后进行。

附注

在优化期间还发现了文件占用时间太长的问题。顺手解决了。

【CVM】 CMS 的编译（寄存器篇）

2018-03-15T00:00:00+08:00

CVM 是采取 AOT 编译方式。 CMS 的每条指令，都会被编译为 (Runtime::Environment &env) -> void 类型的函数。

私有寄存器

CMS 的寄存器是或静态或动态的。每个函数都会对其使用的寄存器进行声明。 mov %1, %2 这样的一条指令，在编译期就能够知道 %1 与 %2 是动态还是静态的。假如 %1 是动态， %2 是静态，那么只需要 env.get_dynamic(1, e_current) 和 env.get_static(2, e_current) 就能获取 %1 和 %2 的数据。

std::function<void(Runtime::Environment &env)> getPrivateRegisterFunc(const FunctionInfo &funcinfo, const InstStruct::Register &reg)
{
    size_t id = reg.index();
    if (funcinfo.is_dynamic(id)) {
        return [=](Runtime::Environment &env){ env.get_dynamic(id, e_current); };
    }
    else if (funcinfo.is_static(id)) {
        return [=](Runtime::Environment &env){ env.get_static(id, e_current); };
    }
    else {
        funcinfo.putError();
    }
}

这样做的好处是不需要在运行期判断，坏处则是编译的代码需要写很多，而且容易错漏。

关于不同环境的编译，因为无法在编译期得到父环境的信息，因此目前全部是 Runtime 期间判断的。

父环境系统的设计只是一个雏形，用于闭包的实现。不过带来许多问题。这方面需要改进一下。（大概会将直接获取父环境寄存器的设计删掉。）

【CVM】【2018.3.15】关于 CVM 的进度与设计构想

2018-03-15T00:00:00+08:00

CVM 在昨天完成了 call 指令的内容。现在，已经可以执行用 CMS 生成的关于各种函数的调用和参数的传递了（已经可以初步嵌入）。

我构想了一个 TinyChill 项目。这个项目是专门用于嵌入的。它使用 CVM 作为后端，目标是轻量化。这要求 CVM 必须达到轻量的级别。能做到跟 lua 的解释器一样好还是很难的。

现在 CVM 充满了 bug 和内存泄漏……静态寄存器的数据不自动释放没什么问题，但是动态寄存器的数据本就是要有管理的。目前都是各种 Alloc ，只申请不释放，想要直接应用还是不行的。（起码先把bug修了。）

关于内存管理，我准备祭出我当年写的 TinyGC 项目。这个 TinyGC 被人说过太中二 233。嘛，直接用在 C++ 上还是不够好的。但是用在虚拟机上还是可以的（大概）。

TinyGC 其实是个筐，什么都可以装。我准备做成一个即插即用型的，带有各种插件的东西。统一好接口，对各种内容进行管理。什么 mark-sweep，什么 reference counting，什么 map manager，都可以放进去。同时，TinyGC 是一个协助型的。有许多子 TinyGC 系统，每个系统之间可以进行信息的交流。使用局部而不是全局管理是 TinyGC 的设计目标。

基于以上，CVM 被设计成一个可以分割成许多子系统（子环境）的系统。

CVM 的源码中不存在全局变量（除了 config.h 里的东西）。在一个引用了 CVM 的程序里，创建多个 CVM 实例也不会发生任何冲突（CPU流水线冲突啥的除外）。同时，我还要给 CVM 之间加上信息交流的通道。让多个 CVM 可以互相协作。

我的一个大构想是，许多语言的VM，什么 JVM，什么 python’s vm，都可以放在一起，进行交互。

现在的交互，主要还是编译为同一种字节码/汇编。比如 .NET 上的 IronPython ， JVM 上的 Jython。这样的实现固然能解决问题，但是并没有保留一个完整的语言实现，相当于重写了它们的编译器。IronPython 3 迟迟没有支持完善好，我觉得还是因为工作量太大的缘故。

如果可以利用现有的语言实现，通过在它们上面开洞，从而实现多个解释器/虚拟机之间的交互，我认为是一种不错的思路。

那么怎么交互呢？

不同的实现之间，语言不通，想要交流，必须能够相互理解。而这个时候，就需要一个“中间人”。

没错，以 CMS 为核心的 CVM，就是起到了“中间人”的作用。

如果你看过 CMS 的文档就可以发现， CMS 的核心是 call 和各种 data register。 CMS 没有算术指令、系统调用指令。算术运算、系统调用等许多指令是通过 call 指令实现的。 CMS 很难在不进行扩展的情况下编译为一个实用的机器码程序。

这似乎是一个缺陷。但是，这是 CMS 有意为之的设计。如同 lua 一样， CVM 的内核是精简的，同时可以方便地进行扩展。

这有如下几个好处：

容易嵌入到其他的语言实现中
容易实现
容易扩展
容易优化

正如前文提到的，CVM 之间能够相互理解。再加上嵌入的特性，可以通过多个 CVM 来实现不同语言实现之间的交流。不同实现只需要能够进行与 CVM 之间的交流，就能够进行相互之间的交流。——这就是 CVM 的伟大理想。

Hello World!

2018-03-14T00:00:00+08:00

The Chill Language

Documentation

ICM Interpreter

(defunc main []
	(print "Hello World!")
	(return 0))

The CMS Language

Documentation

CVM

.program
	.entry main

.datas
	.string #1 "Hello World!"

.func main
	.stvarb 1, cms#pointer
	loadp %1, #1, cms#pointer
	call %0, Chill#Core#print, %1
	ret

Chill Magic’s Blog

【CVM】【2018.3.22】CVM 的内存占用优化（二）

优化前后内存占用的对比

优化1 ： 面向对象的 Instruction 基类添加 virtual 析构

优化2 ： 重构 parser

优化3 ： 提前析构 parser

【CVM】【2018.3.16】CVM 的内存占用优化（一）

优化前后内存占用的对比

测试样例

优化前结果

结果分析

第一次优化（对 runtime 进行优化）

第二次优化（对 compiler 的优化）

总结

附注

【CVM】 CMS 的编译（寄存器篇）

【CVM】【2018.3.15】关于 CVM 的进度与设计构想

Hello World!

The Chill Language

The CMS Language

优化1 ：面向对象的 Instruction 基类添加 virtual 析构

优化2 ：重构 parser

优化3 ：提前析构 parser