Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Broken Promises of MRI/REE/YARV

timetobleed.com

Post reply on HN
Print view View original

71–75 of 75 posts

Re: The Broken Promises of MRI/REE/YARV

#71

Post by CPlatypus »

epochwolf wrote: post #4
[deleted] wrote: post #2

[deleted]

MRI = Matz's Ruby Interpreter = Ruby 1.8 YARV = Yet Another Ruby VM = Ruby 1.9 REE = Ruby Enterprise Edition = Ruby 1.8 with a modified garbage collection system to make it friendly to vforking. These are all versions of ruby written in C.

Damn, your reply and the other four pointing out that they're Ruby VMs reflects very poorly on the intelligence of HN commenters. Did you guys even RTFA? I know these are Ruby VMs, but the article is about the C code that's used within them. That's the only place where "volatile" has any meaning at all. Maybe "volatile" really is unknown among Ruby programmers, but among the people who implement interpreters for Ruby or any other language I can assure you it's pretty common knowledge.

I confess, I just don't know how to deal with such epic stupidity more gracefully than this. Sheesh.

Re: The Broken Promises of MRI/REE/YARV

#72

Post by msbarnett »

ice799 wrote: post #69
msbarnett wrote: post #56

Earlier quoted context omitted.

In practice crashes due to this issue simply do not occur very often. I think I've had the VM segfault twice in the last two or three years. That's what makes the hyperbolic tone of this article so douchey; he wrote up an interesting dissection of an edge case issue as though it were an ongoing catastrophe, mostly just to inject a bunch of chest-thumping rock-star bravado that added nothing of value to the discussion…

You are totally missing the point, bro. The question really is: how much data corruption is occurring that _does not_ cause world ending segfaults? THAT is what you need to worry about. Check yourself before you wreck yourself.

That is some amazingly selective memory corruption, homeboy. How whack is it that it is causing neither widespread segfaults nor widespread reports of creeping data corruption despite these VMs having logged billions of hours of CPU time in production all over the planet, dawg?

And yo check this: maybe this "fatal flaw" is actually just an edge case bug that isn't cropping up much in practice. Fo'shizzle!

And maybe we can drop the ridiculously asinine slang and douchey bravado, "bro".

Re: The Broken Promises of MRI/REE/YARV

#73

Post by ice799 »

msbarnett wrote: post #72
ice799 wrote: post #69

Earlier quoted context omitted.

You are totally missing the point, bro. The question really is: how much data corruption is occurring that _does not_ cause world ending segfaults? THAT is what you need to worry about. Check yourself before you wreck yourself.

That is some amazingly selective memory corruption, homeboy. How whack is it that it is causing neither widespread segfaults nor widespread reports of creeping data corruption despite these VMs having logged billions of hours of CPU time in production all over the planet, dawg? And yo check this: maybe this "fatal flaw" is actually just an edge case bug that isn't cropping up much in practice. Fo'shizzle! And maybe w…

the gzip bug mentioned did not segfault. it simply corrupted the gzip file in memory. not that selective son.

imma talk the way i talk and dont give a fuck if you like it or not.

Re: The Broken Promises of MRI/REE/YARV

#74

Post by fanf2 »

iam wrote: post #40

I think this is a problem that exists across any VM that implements a GC, not just Ruby. .NET CLR has the exact same problem (perhaps a harder one, since CLR has a moving GC), so anytime they touch GC references (pointers to objects that are collectible) it's always wrapped in an explicit GC stack frame (think GC struct that lives on the stack). Furthermore, all reads/writes are carefully done with macros (which of c…

There are other ways to structure the VM's API so that all VM objects are connected to VM data structures at all times. A good example is Lua, where you manipulate Lua objects on the Lua stack - they are never referred to by a raw C pointer.

Re: The Broken Promises of MRI/REE/YARV

#75

Post by judofyr »

ssmoot wrote: post #23
judofyr wrote: post #9

Earlier quoted context omitted.

MRI - Matz' Ruby Interpreter (the default Ruby) REE - Ruby Enterprise Edition (unofficial branch of Ruby 1.8) YARV - Yet Another Ruby VM (the VM used in Ruby 1.8) (Although in this case I think he means MRI = 1.8 and YARV = 1.9)

Minor correction, YARV, written by ko1, has never been a part of the Ruby 1.8.x line to my knowledge. Some language features, (mostly stdlib I think) were back-ported in 1.8.7, but 1.8.x is and always has been an interpreter where 1.9.x has always been YARV (a VM). Useless trivia: Once upon a time Ruby2 was going to be called "Rete" IIRC. Or maybe "Rite"? I doubt it's in any shape to be called a "formal" plan at this…

Damn, that's a pretty big typo. You're absolute right. Can't change it now though :(
Post reply on HN