From: Brent Roman <brent@...>
Date: 2008-12-02T04:47:46+09:00
Subject: [ruby-core:20194] Re: Promising C coding techniques to reduce MRI's memory use


Brian,

gcc optimizes the big switch in rb_eval() into a dispatch table both
before and after my factoring of it into separate node handling functions.

I realize that the Ruby world has moved on, which is why I'm not
going to bother with more work on this until at least a couple folks
commit to testing it.  The 1.8 series is similar enough to 1.6.8 that
I know I could create a patch patch for it in a few days.  If that tested
well,
I might consider trying it with 1.9, but I suspect that would be a lot
more effort.  If 1.9 is using the same GC and gcc as 1.8, then I would
expect that it would benefit from this patch.  However, that remains
to be proven.

Also, 1.9 and its "standard libs" have gotten so large
that they simply won't fit on my target (embedded ARM linux) machines.
The 1.8 core is really not that much bigger than 1.9, I'd just have to
strip away most of its new "standard" libs.
Does anyone know the current status of "Atomic Ruby?"

As Paul as already pointed out, Matz and Koichi kept callcc
in v1.9 Ruby via some very amazing code hardwired into the VM.
It is made accessible after require "continuation". 

I've traced the reliability issues with continuations to the fact that
the GC object mark function for them is incorrect, and posted
a patch to fix this in v1.8.6 about a year ago.  That fix was never
implemented
so continuations continue to have a bad wrap.  My own experience is with
them
since than is quite good.  However, Paul Brannan told me that he has had
trouble with them due to their incompatibility with some of the non-standard
libraries with which his application links.  (Something about call backs, if
I recall correctly)

In any case, Continuations are more general than Fibers.
Fibers can be implemented in terms of continuations quite readily, but 
Continuations cannot be implemented in terms of Fibers.

- brent


Brian Candler wrote:
> 
> Did you replace the whole switch statement with a dispatch table? That
> sounds like a sensible thing to do anyway.
> 
> OTOH, if this is for ruby 1.8.x, I'm afraid you may not find much interest
> in such changes while the focus is all on 1.9.
> 
> Perhaps worth checking how 1.9's bytecode interpreter stacks up under the
> same conditions?
> 
> OTOH, 1.9 doesn't have callcc anyway, so maybe your application code would
> need a lot of restructuring to use Fiber instead. I don't know if it's
> possible to implement callcc in terms of Fiber.
> 
> Regards,
> 
> Brian.
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A19846---Bug--744--memory-leak-in-callcc--tp20447794p20778359.html
Sent from the ruby-core mailing list archive at Nabble.com.