From: Ruben <Ruben.Vandeginste@...>
Date: 2004-07-21T17:54:41+09:00
Subject: Re: Ruby Specification

At Wed, 21 Jul 2004 14:05:43 +0900,
Lothar Scholz wrote:
> 
> 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

Do you use it as a drop-in replacement for "malloc" ?  Because, from
what i remember, this GC provides several functions to give it more
precise information about the data in your heap. I think there are
functions to tell it to allocate for example a chunk of memory for
binary data for which you, as the programmer, guarantee that it will
never contain pointers.

> 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.

This behavior depends for a great deal on the behavior of your
application. For BDW, fragmentation could only be improved by having a
better allocation strategy.

> 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.

Compacting is only possible if you know the root set and have exact
information about which cells contain a pointer and which cells
don't. AFAIK, a pure compacting collector isn't possible with ruby
because of the C extensions... or scanning the raw stack for finding
pointers in the root set (?)

Ruben