Lothar Scholz wrote:

> Hello Jeff,
> 
> 
> JM> Of course the probability of such a collision is small, but it doesn't
> JM> hurt to know it is there.  For long-running daemons using many objects
> JM> and/or ruby C code using lots of stack space it may possibly be
> JM> something to consider, though I haven't looked at the numbers yet.
> 
> Arachno Ruby as a larger program is using the Boehm Weisser GC. That
> does not only consider all elements on the stack but also everything
> in the heap as possible pointers, so there are many things that can be
> wrongly considered as a still in use data. But this seems to be not
> the problem, when i compare it with the exact SmartEiffel Internal GC,
> the overhead in non released data seems to be around 20%. The much
> more serious problem in the Boehm Weisser GC is the high internal heap
> fragmentation it seems to get stable after having 5 times the
> dataset size, from previous posts here i believe that the ruby GC is
> working well.
> 
> So if we ever change the internal memory managment (i
> guess we do not) in ruby, then i hope it will also include a
> compacting GC. In the meantime a lazy mark with write barrier and lazy
> sweep would be a good thing to add. I found that the GC can give you a
> huge time penalty because it simply runs to often and there is no way
> to customize this.
> 
> 
> 
Fascinating stuff.  You sound MUCH smarter than Lothar of the Hill 
People (played by Mike Meyers).  And your Arachno Ruby IDE looks really 
  cool too.

IMHO, I think it would be good to leverage all the research and millions 
already invested by Sun, IBM, et al. in improving java's gc.  I think 
java provides some command line options related to garbage collection.

No need to reinvent the wheel--unless the existing wheel isn't round. :)

I think Ruby 2.0 is very lucky to be looking into bytecode generation 
and gc today because of all the work done recently by others.