买房告一段落

早上去交了公积金贷款申请表，完成一大堆的纸张的填写，好久没有写过这么多的字了。写了还没完，单位开的未婚证明不管用，还得用民政部门办理的，中午回公司吃饭，下午两点钟又出去办理未婚证明，幸亏下午没遇上什么麻烦，虽然在修路，只有106公交车，连一路的站都没写，上去之后运气不错，竟然是直达市府广场公积金办理的地方。交表，完毕。
本来下午请了很长时间假，办完才4点钟，准备压压马路，去书店享受一下难得的假期。结果书店盘存，Lp 打来电话说她加班了，我又去上班了。。。。10路车也巧经过买的房子的工地，夕阳之下，看着渐渐移动的房屋，忽然感到一种特别的感觉。高中，大学，恋爱，买房，这是我要的生活么？还是一段执行良好的程序。那些插曲仅仅是一些没有意义的中断。
想了一些乱七八糟的，买房告一段落，等着通知吧。但愿没有别的麻烦事情，真烦啊！

生活还要继续！我该为自己考虑一下了，我该怎么生活，该怎么生活，我希望我接下来执行的程序是自我编程。。。

Google Android 的野心？

最近关心了一点点Android的新闻，sdk下载了但是懒得去看了。倒是挺关心Android的那个Java虚拟机，看来Google的虚拟机是整个重做的，Compiler也是自作的，而且不是Sun的规范，出来的bytecod也不是Sun的。只有Java 语言接口是标准Java.  背上了分裂Java的罪名。
不过我猜测，Google android极可能作为一个统一的虚拟机平台运行除了java之外的语言程序，这些程序使用官方的语言语法和各自的标准，但是compile之后统一成google自己的Bytecode. 这样更像一个手机上的.net了。。

GC MASK算法的更新

最近还在重构那个设计。
对Mask的算法在增加一些更新：

不使用Stack的3p算法，耗费比带Stack算法并不底，因为那个当前孩子计数器省不掉，而在Stack算法里面，这个计数器放在mask stack上面的。比所有的Object都有个计数器肯定要小很多。所以3p算法的最大优点还是为了避免了栈的使用，因为栈的尺寸不可预料。同时3p算法的独创在于不需要Parent指针的缓存（一个对象一个，太恐怖了）。

带Stack算法在网上看到一个IBM JAVA GC的一些实现的描述，提到了stack overflow 的一些处理。有参考价值，不过懒得去模仿了。

推翻原型，痛苦

在做数组的时候，我才发现我似乎应该把GC/Heap/RefTable 和 OO FrameWork解开。
麻烦啊，我不知道是不是该继续做下去。
问题是：我做数组的时候，数组是一个对象，其中引用的存储需要动态分配并且分配在GC Heap里。然而现在的原型大量依赖Object/Class内存布局来访问Heap, 包括GC的算法，我感觉这是不对的。想想，想想。。。
一开始的想法太简单了，现在似乎不大对了，天啊！！！

Heap实现

今天把Heap实现了，GC下的Heap非常简单方便。
当Mask动作完成后就对Heap作Compacting操作（紧缩）。没了碎片没了垃圾。目前的想法事先做一个Heap.分代收集还得考虑一下。应该是需要多个子Heap.
昨天把分代的想法放在Ref node link是不可行的，耗费太大。因为需要大量移除操作，所以可能需要双向链表，太浪费了。还要思考一下。应该是Mask的时候是针对所有的对象Mask, 分代只是在收集的时候才有区分，因为收集操作是最耗时间的。

紧缩算法很简单，稍微思考一下主要防止移动之后的读取错误（写后读），就是先按照对象长度移动指针，然后在把这个对象剪切到堆尾。因为对象长度可能超过队尾到当前的距离，所以剪切会破坏当前的数据。

紧缩的过程中需要修改Ref node 的指针，所以Object 加了一个域存储Ref node.暂时的方案，有点浪费，到时候再看有没有简单的办法。

房子合同今天才备案

我说怎么这么长时间还没备案，1个多月了。 昨天晚上打电话，说11月底。 今天白天找了一个业主群，才发现都是这样。于是就开始投诉，有在书面的，我在网上投了。结果下午就备案了。。真晕。 烦这些鬼事情！

重构GC和Ref table代码

代码有很多的坏味道，今天抽空重构。主要GC和Ref management之间的关系。我无法确定现在能否在一个Ref management上面去做可选各种GC实现。
为了所谓效率，干脆把接口定义为宏，主要是遍历Ref table和访问的接口。另外Ref table数据对GC都是透明的。
还得思考如果加入世代收集的机制，是不是能管用。简单的说，如果分两代，可能需要另外的数据结构来管理，Ref table肯定只有一个，因为这个是向量，是Ref寻址的基本。但是一个oBject 可以是动态的某代。处于效率的考虑，每次GC Mask的时候不需要遍历真个Ref table. 而只需要访问某代的序列，因此可能要将他们串起。现在原型里面的实现是Mask所有的，这个肯定太弱了，必须支持部分Mask。这个部分可能要用代来区分。要保证未访问的节点，虽然没有mask ,却不能被收集。
妈的，感觉做的越来越复杂了，怕身陷不能自拔。

QQ上看见狗亮了

今天竟然看到狗亮在线，得知他现在回到张家口了。 听说小飞也回家了，在西安结婚了。 那些日子结束了，我的朋友们，激荡的不需要梦想的青春结束了。 才发现，我彻底戒烟一年多了把。。。

原型的代码

这几天稍微有点空，就开始了写源代码。目前完成了Reference table. 在写GC mask 和unit test.
代码还挺多的，还有unit test很麻烦。。。。
GC Mask这边先用一个递归的版本运行起来，然后整个走通后再把这个替换成那个3p算法。-_-`
三个人名字太长了Deutsch-Schorr-Waite 。

写测试用例真是太麻烦了。

引用的规范

基于在C里面实现GC的复杂性，把引用的规范先定下来。
GC mask的时候，认为引用的根是一张虚拟的全局引用表对象，这个引用表对象引用所有的全局对象。GC顺着对象引用遍历所有对象来mask他们为可用对象。
对于存储引用的C变量,如果他们在栈上，寄存器里，或者某个地方不会被mask, 用户需要把他们全局化（增加全局引用的次数）。
这里引用次数仅仅在于全局，对象之间引用不增加引用次数。
将全局引用表视为一个对象，其中含有各种对象引用，并且对每个对象引用多次。
用户也可以weakly use一些引用，这些引用仅仅是一些引用的副本变量，比如用户存储这些引用仅是为了记录而不想发生Leak.

现在可以作一些基本的设计了，Reference 格式和Refernce node的结构也暂时定了下来，还差一些原型的编码。还要做很多改动。

C的GC最大难度其实是接口

我想应该放弃跟踪C调用栈的做法，原因很简单，第一是速度慢，根本无法接受。另外这样很不雅，很麻烦，而且更容易出错。
这几天偷闲的思考这个问题，一直没个眉目，感觉最大的难度不在于GC的如何实现，而在于如何定义这种接口。有多少透明性，多少封装，多少糖衣。。。


真的很难，如果让这个东西不退化为句柄，如果定义用户该做那些必要而又简洁的事情。

==========分界线=============
最近在想要不要不以前的那些Blog转过来，感觉很多舍不得扔掉，当年逃亡此地，也是为了落个清净。那些伤感，幼稚和可乐的文字。

汉编之热

最近网上汉编越来越热，在 CB上面你来我往，什么某某N评，什么专业人士看待，然后汉编自己人也一会民族大义，一会鼻涕眼泪的JJYY...后面竟然大BOSS出来了，那个传说中的教授，吴克忠。。。。。。给汉编呐喊助威。 骗科研经费也就算了，真的以为人民群众是瞎子？ 互联网上，你就是一条狗

C里面实现GC的难点

上班真麻烦。

白天只能上班的时候偷偷的写点伪代码来打草稿。目前的模型基本上是基于C里面最常用的OO方式。当然，指针是不能暴露出来了。目前的思路是：

GC处于等待状态，除非被唤醒。
GC被唤醒仅仅因为需要GC并且Mem Reader Count == 0;
唤醒后挂起所有线程。（这个在嵌入式平台上只要关闭所有中断，但是别的系统还没想好，一个可接受的实现是借用目前GC用来保护读写锁的信号量互斥）。
MASK & CLEAN
继续等待。

GC有个crit和leave,crit里面会增加Reader计数。leave减之。
当某个类的实现需要解开引用去拿指针的时候，必须调用crit之后才能使用。防止指针被移动（GC的实现会对指针作改变）。

比较麻烦的是栈上的引用，C的栈是我无法控制的，不可能象虚拟机实现去遍历栈获取可用的引用，另外也不想用户通过deleteRef 这样的方式，因为这样就牺牲了很大的GC的好处。容易Memroy leak. 目前想的是一个比较低效的做法：
每个成员函数进入需要调用frame_enter，返回需要frame_leave.

frame代表当前的函数框架，同样很多frames表现为Stack形式。Frame里面自动存储以下引用：
new_object返回引用。
某个其他满足此规范的函数返回的引用。
当函数返回时：
如果有返回值是一个对象的引用，则添加到上一层调用者Frame的引用表。
弹出当前的frame.
GC在扫引用的时候，frame就代表了传统意义的栈。

难点又来了：线程怎么办。。
一般来说，一个线程就有一个Frame Stack.
但是必须由当前线程的环境ENV概念（比如JNI的JNIEnv）
目前比较麻烦的是如何生成ENV,如果类似与JNI的话，就需要用户主动ATTACH到线程。并且，所有的函数需要ENV参数。烦的很！如果把这ENV们存储到一个Thread ID的hash表里面倒是也行。根具当前Thread ID取查询对应ENV, 但是每次的上锁访问Hash表查询也是一个比较慢的办法。

如果使用者用起来的比较麻烦，这个也就失去了意义，说不定最后还是返回到DeleteRef这样的机制更容易让人接受。烦的很。

全局的引用时必须手动deleteRef的，相当于这个框架和外界并用的接口。