[#144] Another implementation of Bignum — "Dmitry Antipov" <dmitry.antipov@...>
Hello Ruby hackers,
15 messages
2002/06/06
[#151] Re: Another implementation of Bignum [tarball attached]
— "Dmitry Antipov" <dmitry.antipov@...>
2002/06/07
Hello again,
[#152] Re: Another implementation of Bignum [tarball attached]
— matz@... (Yukihiro Matsumoto)
2002/06/07
Hi,
[#174] Improving Ruby's garbage collector for interactive apps — Matthew Bloch <mattbee@...>
re: this problem I had a few weeks back:
8 messages
2002/06/19
[#177] Re: Improving Ruby's garbage collector for interactive apps
— matz@... (Yukihiro Matsumoto)
2002/06/20
Hi,
[#178] Re: Improving Ruby's garbage collector for interactive apps
— Matthew Bloch <mattbee@...>
2002/06/21
On Thursday 20 June 2002 18:54, you wrote:
[#186] Steps to get multiple interpreters per process... — Sean Chittenden <sean@...>
Can someone chart out what would need to happen to get multiple ruby
10 messages
2002/06/24
[#187] Re: Steps to get multiple interpreters per process...
— matz@... (Yukihiro Matsumoto)
2002/06/25
Hi,
[#188] Re: Steps to get multiple interpreters per process...
— Sean Chittenden <sean@...>
2002/06/25
> |Can someone chart out what would need to happen to get multiple
[#191] Re: Steps to get multiple interpreters per process...
— Chris Ross <chris@...>
2002/06/25
Re: Improving Ruby's garbage collector for interactive apps
From:
matz@... (Yukihiro Matsumoto)
Date:
2002-06-20 17:54:36 UTC
List:
ruby-core #177
Hi,
In message "Improving Ruby's garbage collector for interactive apps"
on 02/06/19, Matthew Bloch <mattbee@soup-kitchen.net> writes:
|So from my survey of gc.c, Ruby's collector is the simplest possible mark &
|sweep algorithm which necessarily halts the whole system to do its work, and
|is conservative in that it doesn't necessarily find out about all garbage
|(because it must guess at what's a pointer and what's not). Is this correct?
Yes and yes. Generational mark and sweep algorithm was done before,
but it was not good enough, probably due to write barrior cost.
|Initially I suppose I'm looking for the simplest possible hack to try to
|smooth out the bumps but currently I'm still looking into the way that other
|parts of the Ruby interpreter are required to support the garbage collection,
|since this obviously will influence my choice of technique. I'm still
|looking into this, but in the meantime if anybody has any thoughts as to what
|direction they'd like to see this work take, I'd be interested to hear it,
|especially from Matz or other veterans of the Ruby memory management.
It should be conservative, to make extension development easy and
reliable. At least, I want extension writers not worrying about
reference management. I really hate GC_Protect and INCREF.
matz.