I don't really see the reason why the GC would need or want a specific thread to itself - for a start, such a design makes the system slower on low end systems. There may also be cases where it is possible to choose 'optimal' times to run the GC within a single thread context.

One thing regarding the GC I am unsure about are the conditions under which the GC is actually run. One not uncommon problem with external libraries (classic and common example is RMagick) do not malloc using the correct api, Ruby often fails to call the GC, at all.

A call to GC.start under these conditions can prevent an OOME, as calling GC.start does in fact cause RMagick to free memory - but ruby doesn't know about this.

The simplest solution to this issue I can see is to ensure that the GC is run when an OOME occurs, or more particularly, all loaded extensions are told to free when an OOME occurs (this does not seem to happen under these conditions). Whilst I know this is not really the responsibility of Ruby, this simple addition could solve problems for quite a number of scripts, thus removing a FAQ.

More regular GC runs may actually be sensible, depending on the real performance issues that might arise with longer running applications and fragmentation. A documented example of such a problem, and a solution is here: http://zdavatz.wordpress.com/2007/07/18/heap-fragmentation-in-a-long-running-ruby-process/

Robert Klemme wrote:
> On 15.10.2007 18:45, Robert Klemme wrote:
>> On 15.10.2007 17:24, Roger Pack wrote:
>>>> |ensure_uninterruptible # (or call it ensure_critical)
>>>>
>>>> It's not as simple as you've expected.  First we need to define how
>>>> "uninterruptible" section work.
>>>
>>> I agree.  One definition would be to mark Thread.critical, then runs 
>>> the block, then unmark.  I would use it :)
>>
>> Bad idea in light of native threads IMHO.  Every construct that halts 
>> all threads should be avoided.  If you need exclusive access to 
>> resources you need to proper synchronize on them.
> 
> I meant: in the light of the fact that native threads will come at a 
> certain point in time.  Your suggested feature would make it 
> unnecessarily complex and slow to use native threads (there would have 
> to be regular synchronization on some hidden global lock, which defies 
> the whole purpose of using (native) threads).
> 
>     robert
> 
>