GC suspend all???

[Corey Minyard]

You are dabbling in places where many people are working and things
look pretty difficult (and moderately grim on getting a good general
solution).  What you are talking about is an incremental collector,
and some exist.  I have written one (soon to be GPL), and the Boehm
collector does this now.

This is much more difficult that you imagine, and unless someone has
found something very new it is not possible to design a reasonably
efficient and completely concurrent collector, at some point even an
incremental collector (and all collectors called "concurrent") must
stop all threads to finish it's processing.  The problem is that the
data the GC has already scanned may be changed by the program after
the GC has scanned it, you have to catch these accesses, and reprocess
them.  So when you get to the end, you have to process all the final
data with the other threads turned off so there is no chance of them
modifying it.

I actually started writing this thinking I was on a different mailing
list, but I just noticed it was for Kaffe.  Oh well, I guess I'll send
it anyway.

Corey

Maxim Kizub <M.Kizub at post.skynet.lt> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello kaffe,
> 
> Does kaffe suspends all threads in order
> to process GC? If yes - is it possible to
> modify GC to walk by small steps, i.e.
> process a part of objects, return, then
> process next set of objects, return, and
> so on...
> I'm going to use java as scripting language
> in 3D game, and performing full gc scan
> will likely skip a frame or two of output,
> that is _highly_ unwanted, since with
> smooth 3D drawing skipped frames are
> well seen by human eyes...