分布式计算系统中的GC问题？
ddatsh
JVM平台上的针对大数据场景（分布式计算框架）设计、优化的Garbage Collector Yak
背景
传统分代模型 gc 算法中，小对象先到Young Generation；经历一定阈值GC还存活，晋升至Old Generation；大对象可直接进入老年代
模型弊端：没有考虑分布式计算情景下对象的生命周期
分布式计算中控制过程(Control Path)与数据处理过程(Data Path)界限明显，都用统一GC模型，会频繁GC，扫描全堆，最后实际回收的很少，Full GC(STW)
Spark 1.5后弃用JVM GC，直接用unsafe包内存管理，十分麻烦还易出错
Yak 针对这两种过程中的数据划分不同的space:
- Control Space (CS)
- Data Space (DS)
对于控制过程（比如任务的调度、日志记录等），内存布局与传统的一致，GC还是采用分代模型，分YoungGen/OldGen/Metaspace。控制过程产生的对象小、生命周期短暂，符合分代假设
数据处理过程，其中的对象通常都是很大的、在计算周期中一直需要访问的，Yak提出了Epoch Region，数据对象的生命周期依赖于每个epoch。每个epoch的start与end需要用户来设置（但是很简单）