From: Christian Boos <cboos@...>
Date: 2002-05-23T01:35:17+09:00
Subject: RE: Stymied by Ruby's garbage collector

Hello,

my 2 cents on this issue:

> -----Original Message-----
> From: Matthew Bloch [mailto:mattbee@soup-kitchen.net]
> Sent: Wednesday, May 22, 2002 5:00 PM
> To: ruby-talk ML
> Subject: Stymied by Ruby's garbage collector
>
>
> Hello;
> > Looking at Ruby's garbage collector (from 1.6.7), it seems an
> 'all-or-nothing' proposition.  That is, the whole algorithm is run at any
> point to free as much memory as possible, or it is not.  There's
> no partial
> collection to satisfy what may be a small allocation request.
>

It's indeed a mark and sweep algorithm, everything is first
marked, and then during the sweep phase, all that was not
marked is freed.

> Now my deadline is pretty tight on this, so I'm after some tips to solve
> this in the short term for now :-)  Various solutions present themselves,
> in order of simplicity:
>
> *) Upgrade the game's runtime to Ruby 1.7 -- does this have a
> less lumpy gc
> algorithm?  Or is there an even more advanced version of Ruby around from
> which I could steal just a better gc?
>

Don't know.

> *) Redesign critical parts of the game to stop burning through so much
> damned memory-- but surely this would ruin the maintainability of
> the code,
> to have to scope everything as widely as possible?  Or are there other
> techniques I can use for the same end?
>

I would suggest that you try to run the GC by yourself very aggressively,
so you don't wait till the point there's a lot of things to collect.
It could also result in a much more 'regular' slow down.

> *) Hack the gc algorithm used by ruby_xmalloc etc. to stop recovering
> memory after the number of bytes needed is available, rather than running
> the whole algorithm.  I haven't studied the algorith in detail yet, so I
> have no idea whether this is viable;

Not viable IMHO. I have no idea how generational garbage collectors
are implemented, but I guess this would need cooperation from various
parts of the interpreter (i.e. anytime you modify VALUEs marked in the
current generation and not yet "swept").

Maybe a topic for Rite?

-- Christian



> *) Find the correct places to GC.disable / GC.enable to smooth the more
> visible glitches over-- but I'd be very wary to deploy such a solution
> because it's unpredictable across different systems and in the worst case
> can seize the machine up totally.
>
> *) last resort: leave everything as it is, but deliberately slow
> animation
> loops to assume the worst case.
>
> Can anyone who's been in a similar situation comment?  I assume this kind
> of problem is endemic to games that rely on garbage collectors,
> so someone
> must have some opinions :-)
>
> thanks in advance,
>
> --
> Matthew
>
>