K-GC

K-GC ，一个为 ILBC / D++ 写的 GC 。

一个简单的 GC 模型尝试。

K-GC 架构下，中间代码（C 语言代码）在引用赋值时，会记录对象的引用关系，这样做的目的是为了让 GC 工作时可以随时暂停，比如 K-GC 工作时，扫描了 1000 个对象，还没扫描完，还有 800 个对象， GC 可以停下来，让应用程序接着运行，下次 GC 启动接着扫描回收。

一般的 GC 在扫描时是不能暂停的，必须把扫描全部做完才能挂起 GC，让应用程序线程运行。如果 GC 中途停止扫描，让应用程序线程运行，那这次扫描白做，下次 GC 启动要从头重新扫描一遍。

K-GC 虽然可以随时暂停扫描，下次运行接着扫描，但也因为这样， K-GC 的性能不太高。

为什么要做 GC 暂停扫描这方面的研究尝试？因为 ILBC / D++ / K-GC 架构有一个目标，就是要消除 GC 导致应用程序的暂停（挂起）。

在 ILBC / D++ / K-GC 架构的研究中，还提出了 Pool 和 Bag 的概念， Bag 是一个独立的内存区域，在这个内存区域内，可以分配空间，创建对象，建立对象图， Bag 有自己的 GC，管理回收对象图。

Bag 的 GC 可以由程序员自己来写。

一个 Bag 同一时间只能有一个线程使用，因此，对 Bag 的使用要加锁（Lock）。

GC 和应用线程之间也通过 Lock 来互斥，使用 Bag 。 GC 要扫描回收 Bag 时，先尝试获得 Bag 的锁，如果 Bag 正被应用线程使用，则 GC 转入等待（可能是挂起或自旋或别的什么，你们看着办吧），下次启动时同样先尝试获得 Bag 的锁，如果 Bag 未被应用线程使用，则 GC 获得 Bag 的锁，开始扫描回收， GC 占有 Bag 的锁的期间，应用线程不能获得 Bag 的锁，也就不能使用 Bag 。

也可以在应用线程内直接启动和运行 GC，这样 GC 就不用尝试获得锁， GC 直接运行在应用线程里。

有了 Bag，同学们就可以绕过代码帧、多核、多线程挂起等等底层、复杂、精细、高深、“内幕” 的技术，不用被庞大的技术资料和权威吓倒，可以自由的自己写一个自己的 GC ，发展计算机语言。

嘿嘿，我是不是把秘密都告诉你们了？

当你们看到 Unity3D 、IL2Cpp 、LLVM 、PostgreSql 玩得那么酷，再看看 Z GC 那么复杂的设计和实现逻辑和底层技术以及厚厚的技术资料和背景，你们要怎么追赶它们呢？

我这里有答案。

再看看 GoLang 的不上不下，再看看 Rust “下一代系统编程语言” 的主流地位日渐确立， C++ 也对 Rust 无可奈何，只有长辈的份，没有批评指教的份，你们要怎么追赶它们呢？

我这里有答案。

GC 和协程的背后代表的，是计算机语言在当代要解决的问题，包括内存管理、多核数据同步、IO 、线程池、高并发、协程优先级评估计算、多核均衡利用。

分级存储对应用程序运行效率的影响和内存管理（堆 / 栈）的应对策略。

分级存储是 CPU 一级 Cache 、二级 Cache 、三级 Cache 、内存、虚拟内存。

这些问题解决在当代，谋划在未来，对计算机架构的未来影响深远。

百度的专家们，你们能解决这些问题吗？作好准备了吗？