c++ - AST 解释语言的停止世界垃圾收集 : prevent application threads waiting for one

Question

我正在用 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 函数)，所有其他应用程序线程和 垃圾收集器线程将等待该线程到达安全点，以便可以执行垃圾收集。有没有办法避免这种情况？

Answer 1

有办法避免这种情况吗？

不适用于您当前的设计，以及您“ native ”代码的明显不透明属性(无法看到/触摸内部)。

您的设计很简单:每个线程必须偶尔位于一个“安全”位置，在那里它不会分配您的语言可以识别的对象，并且它不会在无法识别的位置保存指向此类对象的指针被GC看到。通过坚持强制每个线程定期检查是否需要 GC 的线程协议(protocol)，您可以确保在您为该线程设计的安全位置。

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

鉴于这些行为违反了协议(protocol)，如果您单独留下分配器和 native 代码，您大概无法解决此问题。

因此，您要么必须将协议(protocol)更改为其他内容[并仍然找出解决方案]，要么更改分配器和 native 代码的作用。

您可以通过坚持 GC 和内存分配器共享一个锁来解决 a)，这样在任何时候只有一个可以处于事件状态。这将阻止您的 native 代码在 GC 运行时进行分配。这可能会增加内存分配器的额外开销；也许不是，因为它可能必须防御多个线程运行解释代码并同时尝试分配对象。即使您有线程本地分配器，在某些时候本地分配器也必须用完空间并尝试从所有线程共享的池中获取更多空间，例如，操作系统提供的线程。

您可以通过坚持 native 代码偶尔将其持有的所有指针以其不透明状态存储回公共(public)位置，以便 GC 可以看到它们，并像解释器线程一样暂停来解决 b)。

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

如果你采用第二种方法，你也可以在你的解释器中使用。这将避免每个解释器线程在每个语句后轮询 Gcflags的额外开销。当您调整解释器的速度时(您会发现您希望在它运行时立即这样做)，您会发现轮询在运行时开销中所占的比例越来越大。