[ruby-core:27458] Re: better GC?

Write barriers are expensive, it's *really* difficult to do unless your 
compiler supports it.  I've toyed with using mprotect() to implement 
write barriers, but signal handlers are just too slow.

I think LLVM has hooks for read and write barriers during JIT. Rubinious 
might be good candidate for trying write barriers.  Write barriers could 
enable single-threaded, real-time non-blocking treadmill style collection.

Lately, my solution is to write tighter Ruby code that creates less 
garbage and cache computations as much as possible.  Allocation and 
garbage is never free, maybe we should stop coding like it is.

KAS

Roger Pack wrote:
>> Yes, but unfortunately it's not small at all.  GC has a lot of
>> trade-offs and difficult technical dependency.  It's not that easy to
>> solve your frustration.  I am happy to be proven wrong (that means
>> patches are welcome).
> 
> Does anybody have the (previously unsuccessful) generational write
> barrier GC ruby patch around, by chance?
> 
> 
> A couple of other ideas I had were to
> 1) start GC if GC is "close to being ready to spring" and all existing
> threads enter a wait state [rb_thread_blocking_region]
> 2) have a dual generational GC, like a
> "setup phase" (use the long lived heap)
> then a
> "running" phase (use the normal heap from then on)
> similar to what 1.9.2dev uses now.
> 
> Though I'll admit that typically GC uses only like 10%, with large
> datasets it uses much more.
> 
> Thoughts?
> -r
>