[ruby-core:19576] Re: GC thought

> A way to avoid this [as Boehm does (?)] would be to throw up a write
> barrier during collection and search it in the parent thread for new
> references--I am somewhat scared of doing so since it sounds hard :)

I suppose some more options would be:
if you ever call ObjectSpace.each_object [or dereference a weak hash]
have it wait for any outstandingchild GC's at that point [before
performing it].

You could also keep track if you've used any "resurrecting" functions
such as these while a GC is running, and if you have, ignore the
return value from it.
You could have it do a single threaded GC after  child GC returns or what not.
Just thinking out loud.

I'm not certain if the speed increase is because of threading or
because it runs the GC fewer times when there is more memory in use.
This could use some more research.  I know lloyd's GC tests can be
found at http://lloydforge.org/projects/misc/ -- those and making GC
report stats might shed some light.

Some more speed tests can be found at the bottom of
http://betterlogic.com/roger/?p=496

Thanks!
-=R