« 十年 | 返回首页 | 关于废弃 263 电子邮件信箱的声明 »

C--

元旦这几天没啥心情做项目,老是胡思乱想。

有个问题我一直没弄清楚,那就是静态语言如何提供一套合理的 gc 机制。目前,给 C/C++ 硬加一套 gc 库,显然有超 C 语言的能力。这种库,也不是没有。A garbage collector for C and C++ 这儿就有一个。但是它的内存扫描,是基于一种对指针的猜测。这并非完美的解决方案。

D 语言 支持了 gc ,但跟我想象的不太一样。前段时间读了好多 D 语言的资料,还是不太了解它怎么实现 gc 的。

这几天想走另外一条路子:如果自己写一个 C 语言的前端,好象当年 C++ 干过的那样。该怎么实现最为合理呢?

想来想去,最麻烦的是 C 语言本身对局部变量(即堆栈上的数据)的布局无法控制。这是 gc 在做根扫描时的最大障碍。而全局变量和用户自定义结构中的指针查找,都可以通过前端生成的数据和代码轻易解决。

我想了一个方案是采用双堆栈。系统堆栈只用于函数调用的返回地址,而堆栈数据则分配到另一个自己控制的数据堆栈上。前端去生成每个函数用到的局部变量的内部布局结构。当然物理上放在一个堆栈上也可以,只是实现稍有不同。

这两天查了一些资料,经同事提醒,我翻到了一个不新的玩意,C-- 。以前留意过没深究。今天仔细的读了它的一篇 paper C--: a portable assembly language that supports garbage collection 感觉满有意思的。其中谈到了几点 C 语言的局限性深得我心。

如果真要做这么一个前端的话,port 到 C-- 会是一个比 C 更好的选择。

可惜目前项目压力太大,就算做一次思想实验罢了。

Comments

我想了一个方案是采用双堆栈。系统堆栈只用于函数调用的返回地址,而堆栈数据则分配到另一个自己控制的数据堆栈上。前端去生成每个函数用到的局部变量的内部布局结构。当然物理上放在一个堆栈上也可以,只是实现稍有不同。

------------------------------
嘿嘿,就是FORTH

我个人感觉,gc 在 gui 框架的设计上非常有用。

为什么会想给C加GC呢,什么样的应用必须经常动态分配/释放内存?我看了一下自己这两年写的C/C++ code,基本上内存都是在一开始就分配好的,包括处理时需要用到的各种buffer,直到程序退出才释放。虽然可能总共要分配几百兆内存甚至1G多内存,但操作系统会负责维护workset的,所以其实不浪费物理内存只是占了这么多地址空间。剩下的基本都是stack variable了,偶尔会有一些其他的也是带个stub在stack上的(RAII的)。这些主要都是server-side的程序。据我所知embedded application一般也都是这样做的,因为动态内存分配算法可能不是O(1)的会不满足严格的实时性要求。我想C主要就是用来写server-side和embedded这2种应用吧。

上面说的不准确,D语言目前的标准库phobos的实现是标记整理,不排除其它库另写GC的可能,因为GC是可以换掉的,它留了一个接口。目前这个GC似乎多次被人说效率不太高,dsource.org上另外有个标准库ares在编写之中,GC可能会另写,还没看过这个库。

D语言的GC我记得好像是标记整理,在DMD源码里面的phobos/internal/gc/gcx.d里面实现的。

Post a comment

非这个主题相关的留言请到:留言本