Explanation of Azul's "pauseless" garbage collector -

i've read this:

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

although i've experience compilers, i've done nothing related garbage collection; big black box me.

i've struggled understand issues mentioned article. understand problem (there's pause when executing garbage collectors), , understand claim implementation doesn't have problem. don't understand why/how problem happens in first place (that seems assumed understood on original text), , in consequence don't why solution might work.

can explain me:

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

i tend understand kind of things better when explained graphically - small memory schema done code editor suffice.

thanks!

they talk pause inevitably occurs when compacting heap. see, when allocate , deallocate lots of objects of different sizes go, fragment heap (much fragment harddrive). when fragmentation becomes extreme, have clean up/defragment/compact heap reserving huge chunk of memory, moving objects there (without fragmentation) , use former locations fresh chunk of memory without objects in it, i.e. without fragmentation.

when that, invalidate references objects moved around. prevent this, must prevent reference refers pre-compaction object location used. far easiest way pause whole application, move objects around , go , update references. of course can incur significant overhead.

so solution azul proposes goes this: establish "read barrier" allows gc intercept dereferencing, , way can lazily update references used.