Explanation of Azul's “pauseless” garbage collector?

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.

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.

Oh! So cleanly explained! Thanks a lot!

– kikito Dec 20 '10 at 16:24.

(yes you'd have to track all pointers to an object of course).

I would really like to know this too :) – skyde Sep 12 at 20:33 Just think about the memory complexity of tracking all pointers to an object. And then imagine you do that for all objects, not only for those which are currently moved around. And then think about multithreading.

You'd have to synchronize every change of those tracking lists. If that hasn't convinced you, think about cache behaviour. Smart pointers, aka.

Reference counting or your tracking lists mean that every pointer assignment has to access additional and recently not used memory locations. Therefore your caches are much more trashed. – jmg Sep 29 at 12:12.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.