Azul的“暂停”解释垃圾收集器 [英] Explanation of Azul's "pauseless" garbage collector

问题描述

我刚刚读过这样的内容：

http://www.artima.com/lejava/articles/azul_pauseless_gc.html

虽然我在编译器方面有一些经验，但我与垃圾收集没有任何关系;对我来说是一个很大的黑盒。

我一直在努力去理解文章中提到的问题。我理解这个问题（执行大多数垃圾收集器时有一个暂停），我明白他们声称他们的实现没有这个问题。但我不明白为什么/如何在第一时间发生问题（这似乎被认为可以在原始文本中理解），因此我不明白他们的解决方案可能起作用的原因。

有人可以向我解释：

1. 为什么垃圾收集器会有一般的停顿
>

2. 为什么Azul的gc没有这个问题？

我倾向于更好地理解这种情况当用图形解释时 - 可能用代码编辑器完成的小内存模式就足够了。

解决方案

他们谈论压缩堆时不可避免发生的暂停。你会发现，当你分配和释放大量不同大小的对象时，你会对堆进行分段（就像分割你的硬盘一样）。当碎片变得过于极端时，你必须通过预留大量内存来清理/碎片整理/压缩堆，将所有对象移动到那里（没有任何碎片），并将它们以前的位置作为新的内存块，而没有任何对象，即没有碎片。

当你这样做的时候，你使所有移动对象的所有引用无效。为防止出现这种情况，您必须防止使用引用预压缩对象位置的引用。到目前为止，最简单的方法是暂停整个应用程序，移动对象然后去更新所有引用。因此，Azul提出的解决方案是这样的：他们建立了一个读屏障，允许GC拦截解引用，而这个他们可以懒惰地更新实际使用的引用。

I've just read this:

http://www.artima.com/lejava/articles/azul_pauseless_gc.html

Although I've some experience with compilers, I've done nothing related with garbage collection; is a big black box to me.

I've struggled to understand the issues mentioned by the article. I understand the problem (there's a pause when executing most garbage collectors), and I understand that they claim that their implementation doesn't have that problem. But I don't understand why/how the problem happens in the first place (that much seems to be assumed to be understood on the original text), and in consequence I don't get why their solution might work.

Can someone explain to me:

1. why garbage collectors have that pause in general
2. why Azul's gc doesn't have that problem?

I tend to understand this kind of things better when explained graphically - probably a small memory schema done with the code editor would suffice.

Thanks!

解决方案

They talk about the pause that inevitably occurs when compacting the heap. You see, when you allocate and deallocate lots of objects of different sizes as you go, you fragment the heap (much like you fragment your harddrive). When fragmentation becomes too extreme, you have to clean up/defragment/compact the heap by reserving a huge chunk of memory, moving all objects there (without any fragmentation) and use their former locations as a fresh chunk of memory without any objects in it, i.e. without fragmentation.

When you do that, you invalidate all references to all objects you moved around. To prevent this, you must prevent that a reference that refers to a pre-compaction object location is used. The by far easiest way to do so is to pause the whole application, move the objects around and then go and update all references. Of course this can incur a significant overhead.

So the solution Azul proposes goes like this: They establish a "read barrier" that allows the GC to intercept dereferencing, and this way they can lazily update the references that are actually used.

这篇关于Azul的“暂停”解释垃圾收集器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！