AST 解释语言的停止世界垃圾收集:防止应用程序线程等待一个

Stop-the-world garbage collection for AST-interpreted language: prevent application threads waiting for one

我正在用 C++ 开发一种 AST 解释型脚本语言。解释器有一个简单的 stop-the-world mark-and-sweep 垃圾收集器,每当触发收集时,它都会向所有应用程序线程发送停止请求,然后等待所有应用程序线程暂停。每个线程只有一个安全点,它可以满足 gc 的请求,放置在每次执行一行解释代码时调用的方法 exec() 中,如下所示:

void Thread::exec(const Statement *stmt){
    if(runtime->gcPauseRequested){
        this->paused = true;
        gcCallback.notify_one(); //notify GC that this thread is now waiting
        gcConditionVariable.wait(gcLock); //wait for GC to be finished
        this->paused = false;
    }
    // execute statement...
}

和垃圾收集器:

void MemoryManager::gc(){
    runtime->gcPauseRequested = true;
    while(!allThreadsArePaused()){
        gcCallback.wait(gcCallbackLock);
    }
    runtime->gcPauseRequested = false;
    //garbage collect and resume threads...

}

问题出在这里:该语言支持本地函数调用,但是对于当前系统,如果线程正在执行耗时较长的本地调用(例如本地 sleep 函数),则所有其他应用程序线程 垃圾收集器线程将等待该线程到达安全点,以便可以执行垃圾收集。 有没有办法避免这种情况?

有没有办法避免这种情况?

不适用于您当前的设计,以及您的 "native" 代码的明显不透明属性(不能 see/touch 在里面)。

您的设计很简单:每个线程必须偶尔位于 "safe" 一个地方,它不会分配您的语言可以识别的对象,也不会在某些地方保存指向此类对象的指针GC 看不到。您确保通过坚持强制每个线程定期检查是否需要 GC 的线程协议,在您为该线程设计的地方是安全的。

您调用的本机函数根本不遵循您的协议。他们可以做两件坏事:a)分配解释语言对象,和 b)在不透明状态下保存指向此类对象的指针(寄存器,GC 看不到的堆栈帧中的变量,在内存管理器分配的对象之外分配的对象中的变量, ...) 的本机函数。

鉴于这些行为违反了协议,如果您单独留下分配器和本机代码,您可能无法解决此问题。

因此,您要么必须将协议更改为其他内容[并仍然找出解决方案],要么更改分配器和本机代码的功能。

您可以通过坚持 GC 和内存分配器共享一个锁来解决 a),这样在任何时候只有一个可以处于活动状态。这将阻止您的本机代码 在 GC 运行ning 期间分配。这可能会增加内存分配器的额外开销;也许不是,因为它可能必须防御多个线程运行宁解释代码和所有尝试同时分配对象。即使你有一个线程本地分配器,在某些时候本地分配器必须 运行 出 space 并尝试从所有线程共享的池中获取更多,例如 [=41] =] 提供。

你可以通过坚持本机代码偶尔将其以不透明状态保存的所有指针存储回 GC 可以看到的 public 位置来解决 b),就像暂停一样解释器线程做。

在本机线程中坚持指针安全的更复杂方法是​​构建其内容的内存映射(最好离线完成),用布尔值标记每条机器指令(或包含代码的缓存行):"safe to GC here" 或 "not safe to GC here"。然后 GC 停止每个线程,询问是否在本机代码中 运行ning,如果是,则获取 PC 并检查相应的布尔标志。如果安全,继续进行 GC。如果不是,则将线程单步执行到下一条指令并检查修改后的 PC。是的,这是一个非常棘手的逻辑。以及如何确定哪些指令是 "safe" 与 "not safe" 是一个额外的(相当大的)问题;如果本机代码的某些部分您不知道答案,您总是可以保守一些并标记 "not safe to GC here"。您仍然指望本机代码不会进入某种没有任何 "safe" 点的循环,或者至少不要经常这样做。

如果你采用第二种方法,你也可以在你的解释器中使用。这将避免每个解释器线程在每个语句后轮询 GC 标志的额外开销。当你调整你的解释器以提高速度时(你会发现你一得到它就想这样做 运行ning),你会发现轮询变得越来越小 运行time开销。