The Broken Promises of MRI/REE/YARV • Hacker News Board

I do appreciate the technicality of the article, but I'm not sure to agree with the first point of conclusion: how does it makes MRI (and related) 'fatally flawed' though? (real question).

What makes it 1/ irreversible and 2/ bad for today's users?

EDIT: as well, I wouldn't stop using Ruby because of that; I would use JRuby or Rubinius or IronRuby (if I understand well, these ones are not affected?)

Re: The Broken Promises of MRI/REE/YARV

#14

Post by wingo » Tue, Jul 05, 2011, 4:23 PM UTC

Cute. The Boehm-Demers-Weiser collector has GC_reachable_here for this reason. Guile has scm_remember_upto_here since before it switched to libgc. I'm sure other systems have their things too.

That said, I like Handle, the RAII thing that V8 uses. It also allows for compacting collection. Too bad C doesn't do RAII.

Re: The Broken Promises of MRI/REE/YARV

#15

Post by thibaut_barrere » Tue, Jul 05, 2011, 4:31 PM UTC

wingo wrote: post #14

Cute. The Boehm-Demers-Weiser collector has GC_reachable_here for this reason. Guile has scm_remember_upto_here since before it switched to libgc. I'm sure other systems have their things too. That said, I like Handle, the RAII thing that V8 uses. It also allows for compacting collection. Too bad C doesn't do RAII.

.Net has GCHandle [1] and I believe the JVM calls to JNI have a similar mechanism (GetXXCritical [2])

[1] http://www.shafqatahmed.com/2008/05/memory-control.html

[2] http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index....

Re: The Broken Promises of MRI/REE/YARV

#16

Post by dlikhten » Tue, Jul 05, 2011, 4:35 PM UTC

thibaut_barrere wrote: post #13

I do appreciate the technicality of the article, but I'm not sure to agree with the first point of conclusion: how does it makes MRI (and related) 'fatally flawed' though? (real question). What makes it 1/ irreversible and 2/ bad for today's users? EDIT: as well, I wouldn't stop using Ruby because of that; I would use JRuby or Rubinius or IronRuby (if I understand well, these ones are not affected?)

I fail to see how this is an all hands abandon ship issue. If its a critical issue in all 3 interpreters they should be fixed asap if possible. At worst with a flag.

If rubinius/ironruby/jruby have no issues, this may become moot eventually as rubinius is gaining lots of traction recently and is becoming faster by the release outperforming standard ruby vms in many cases.

Re: The Broken Promises of MRI/REE/YARV

#17

Post by softbuilder » Tue, Jul 05, 2011, 4:50 PM UTC

Well plus one for a blog post with a theme song, anyway.

Re: The Broken Promises of MRI/REE/YARV

#18

Post by evanphx » Tue, Jul 05, 2011, 4:51 PM UTC

dlikhten wrote: post #16

thibaut_barrere wrote: post #13

I do appreciate the technicality of the article, but I'm not sure to agree with the first point of conclusion: how does it makes MRI (and related) 'fatally flawed' though? (real question). What makes it 1/ irreversible and 2/ bad for today's users? EDIT: as well, I wouldn't stop using Ruby because of that; I would use JRuby or Rubinius or IronRuby (if I understand well, these ones are not affected?)

I fail to see how this is an all hands abandon ship issue. If its a critical issue in all 3 interpreters they should be fixed asap if possible. At worst with a flag. If rubinius/ironruby/jruby have no issues, this may become moot eventually as rubinius is gaining lots of traction recently and is becoming faster by the release outperforming standard ruby vms in many cases.

Neither Rubinius nor JRuby (and probably IronRuby too) have this issue because they all use accurate garbage collection rather than conservative. Accurate requires much more bookkeeping since all pointers must always be properly identified, but if you start writing a system with accurate GC, it's pretty easy. Bugs like this are a direct result of a conservative GC strategy (and these bugs, as I'm sure you got reading Joe's post, really really suck to find).

Re: The Broken Promises of MRI/REE/YARV

#19

Post by davesims » Tue, Jul 05, 2011, 4:53 PM UTC

This post is a weird mix of careful technical analysis and douchey, Zed Shaw-style hysterical overstatement.

However, I would like to see Matz' response to the recommended steps for a fix at the end. Sounds like a reasonable goal to add for Ruby 2.0.

Note to self: Listening to Papoose while writing a technical blog post turns your otherwise important observations into a Chicken Littleish, end-of-the world rant.

Re: The Broken Promises of MRI/REE/YARV

#20

Post by jleader » Tue, Jul 05, 2011, 5:54 PM UTC

dlikhten wrote: post #16

thibaut_barrere wrote: post #13

I do appreciate the technicality of the article, but I'm not sure to agree with the first point of conclusion: how does it makes MRI (and related) 'fatally flawed' though? (real question). What makes it 1/ irreversible and 2/ bad for today's users? EDIT: as well, I wouldn't stop using Ruby because of that; I would use JRuby or Rubinius or IronRuby (if I understand well, these ones are not affected?)

I fail to see how this is an all hands abandon ship issue. If its a critical issue in all 3 interpreters they should be fixed asap if possible. At worst with a flag. If rubinius/ironruby/jruby have no issues, this may become moot eventually as rubinius is gaining lots of traction recently and is becoming faster by the release outperforming standard ruby vms in many cases.

I think the author has a valid point that the "conservative" garbage collection approach has a flaw in its assumptions about the behavior of C compiler optimizations, and it doesn't sound like something easy to fix without a rewrite (i.e. switching to "accurate" GC). This sort of flaw will continue producing new surprising bugs, potentially any time the code is changed, or any time the compiler's optimizations change. These sorts of bugs are frustrating to track down, because they depend both on details of code optimization, and on details of memory allocation/deallocation history. If you compile with debugging options, you may change what optimizations are used; if you insert debug prints for some old-school log-based analysis, you may change the allocation/deallocation history, so the GC gets triggered in a different place.