Lyt
posts - 16,comments - 61,trackbacks - 0

      开发这个垃圾收集器的是为了降低用户使用语言的难度,回避掉内存使用的囧事(比如内存泄漏)。垃圾收集器工作时,需要挂起用户程序,等待释放出不占用的资源后才可继续工作。如何提高垃圾收集器的性能显得非常重要。

1. 垃圾收集器什么时候工作比较合适

      垃圾收集器会在内存耗尽或内存分配达到某个阈值时才进行工作。内存耗尽要进行垃圾收集是自然的,但是这个阈值到底该多大才合适呢?太小会造成垃圾收集频率太高,太大会造成内存利用率降低。这里我只是简单地无视这个问题,等到内存耗尽再进行回收。

2. 多少个分代才合适

      垃圾收集器一个工作周期时长极大地依赖于一次收集中存活下来的数据。分代越小,时间越短,然而,一个较小的分代会比较大的分代更容易填满,从而增大了收集的频率,除非我们更早地提升对象。但是,分代收集是希望尽可能多的对象中年轻的时候死亡,所以对象不应该被过早地提升。这里我只是简单地抄袭了.NET,分成三代。

3. 分代的大小是固定的

      Generation的大小如果能随着内存使用情况来改变就好了,不知道要根据啥规律来折腾,心理没谱。

4. 一刚开始垃圾收集器申请的内存也是固定大小的

      如果内存耗尽,垃圾收集后仍然无法提供足够的内存分配给对象,此时我就只能抛出异常了。有在考虑说,是不是要扩大这个内存,重新申请,重新分配Generation,到底要根据啥规律比较合适暂时还没明白。

5. 什么时候提升对象

      一个对象什么时候提升依赖于这个对象必须在多少次收集中幸存下来。这里我只是简单地在每次收集后就提升所有的对象,即使某些提升的对象实际上很年轻,会使得年轻对象没有死亡机会。

 

      到这里关于垃圾收集器的讨论就告一段落了,欢迎大家来喷~

posted on 2010-05-14 16:34 Lyt 阅读(1819) 评论(2)  编辑 收藏 引用 所属分类: 垃圾收集器

FeedBack:
# re: 稚嫩版垃圾收集器 之 未解决的问题
2010-05-14 18:09 | 陈昱(CY)
如果SmallObject最大大小并不是很大的话~~也许可以根据对象大小弄成多个SmallObjectHeap。

比如对象大小是2,就放在SmallObjectHeap2,
对象大小是4,就放在SmallObjectHeap4,
对象大小是8,就放在SmallObjectHeap8.......

这样就可以省去内存缩并的工作。只有当Heap不够大时,才扩大内存。

不用执行碎片的方法(参考python的实现):
struct BlockN
{
BlockN* m_Free;
char data[N];//大小为N的对象数据
};
class SmallObjectHeapN
{
BlockN m_Blocks[size];
BlockN* m_NextFree;
};
SmallObjectHeapN的类里面有一个指向空闲地址的指针m_NextFree,每个BlockN也有一个指向空闲地址的指针m_Free(初始化成0),
在一开始的时候SmallObjectHeapN的m_NextFree肯定指向m_Blocks的地址;
添加的时候,发现m_NextFree所在的block里面的m_Free是0,于是++m_NextFree;
某个block删除的时候,m_Free=m_NextFree,而m_NextFree指向这个被删除的block;
再次添加对象时,发现m_NextFree指向的block里面的m_Free不是0,则添加完成后,m_NextFree=block->m_Free就行了。  回复  更多评论
  
# re: 稚嫩版垃圾收集器 之 未解决的问题
2010-05-14 22:03 | Lyt
@陈昱(CY)
看懂,我在实现对象池的时候就是用类似的算法。  回复  更多评论
  

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理