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

61–70 of 75 posts

Re: The Broken Promises of MRI/REE/YARV

#61

Post by yellowredblack »

ice799 wrote: post #51
fhars wrote: post #31

Earlier quoted context omitted.

The point is that the GC cannot see that and so assumes that the object is no longer referenced and can be freed. A conservative collector works by scanning the live memory of the process for things that look like pointers into the same live memory and then assumes that all objects that are not the target of any of these pointers are garbage. Tough luck if the only reference to a live object lives in a register.

registers are scanned, too. the bug is not that the ref is in a register. the bug is that there are no refs anywhere. not on the stack and not in any register.

This statement confused the heck out of me (wow! magic free memory) but of course, the pointers are being held to the contents of the memory, just not to the start of the object, which is what the GC cares about.

Perhaps the GC could be modified to track pointers not just to the head of object but to any address within it. Alternatively, C-coders working with Ruby could just say "I'm using this gc object" before calling C code.

I don't see this is a fatal flaw at all. Sounds like its just a bug. Now if, as many here assert, this bug is present all over the Ruby VM, then that's pretty unfortunate. Is that the case, or just hyperbole?

Re: The Broken Promises of MRI/REE/YARV

#62

Post by CPlatypus »

"Very few people out there know that the volatile type qualifier exists"? Only if there are "very few" kernel programmers, embedded programmers, and others who have used C for anything low-level and/or multi-threaded. Otherwise, no. Sorry, but knowing about it doesn't make you special.

"Volatile" is the wrong fix, by the way. That's just depending on yet another non-required behavior. There is in fact no further reference to "str" between the function call and the reassignment at the start of the next iteration, so there's nothing for "volatile" to chew on. This particular version of this particular compiler just happens to add an extra pair of stack operations in this case, but it's not truly required to. A real fix would not only mark the variable as volatile but also add a reference after the function call. The same "(void)str;" type of statement that's often used to suppress "unused argument/variable" warnings should count as a reference to force correct behavior here.

Re: The Broken Promises of MRI/REE/YARV

#63

Post by nwjsmith »

jamesgolick wrote: post #53
msbarnett wrote: post #50

Earlier quoted context omitted.

I'd rather see a technical analysis of Erlang that didn't read like it was written by Kanye West and sponsored by Axe Body Spray.

This would be funny if it made any sense and if it wasn't a ripoff of an old Merlin Mann tweet about DHH.

A _why tweet? http://favstar.fm/users/_why/status/1640180235

Re: The Broken Promises of MRI/REE/YARV

#64

Post by knewter »

msbarnett wrote: post #56
Nelson69 wrote: post #55

Earlier quoted context omitted.

I kind of branded it a bit "douchey" at first too but then as I thought about it, it seemed remarkably restrained considering he debugged this issue. It's not like this happened all the time, had to get kind of lucky and build and calibrate a system just right to capture it. I don't intend this to be an inflammatory question, I'm sort of a perpetual ruby novice, it's never been my day job and I've never managed to so…

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…

I've actually had an ungodly metric ton of ruby segfaults in the past month or so, and almost never before that. At least one of them has definitely been GC-related - see "therubyracer is not thread safe" for one problem I've been running into. You also have to use PassengerSpawnMethod conservative to avoid GC-related failures in passenger with rails 3.1.

I'm not sure if those are both related to this or not, but I've had drastically more segfaults lately than in my past 6 years of ruby programming. It's getting pretty bad imo.

Re: The Broken Promises of MRI/REE/YARV

#65

Post by knewter »

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…

It was "Rite." Now Matz is calling the embedded ruby he's working on with some japanese electronics manufacturer by the name "Rite." RubyConf 2010 keynote covered it in detail.

Re: The Broken Promises of MRI/REE/YARV

#66

Post by onedognight »

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.

While C doesn't support RAII, gcc does: https://secure.wikimedia.org/wikipedia/en/wiki/Resource_Acqu...

Re: The Broken Promises of MRI/REE/YARV

#67

Post by tsuyoshi »

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…

Anyone who has written an extension to a garbage-collected language in C will have run into this issue. Personally I've written extensions for Guile, OCaml, Ruby, MLton, and Java, and all of them have tricky rules for making your C code safe for garbage collection. Using volatile is the wrong way to do this though... this tells me that the people figuring this stuff out for Ruby don't really know C that well.

Re: The Broken Promises of MRI/REE/YARV

#68

Post by riffraff »

knewter wrote: post #64
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…

I've actually had an ungodly metric ton of ruby segfaults in the past month or so, and almost never before that. At least one of them has definitely been GC-related - see "therubyracer is not thread safe" for one problem I've been running into. You also have to use PassengerSpawnMethod conservative to avoid GC-related failures in passenger with rails 3.1. I'm not sure if those are both related to this or not, but I'v…

but how much of that is the interpreter's fault?

I know I can't run typhoeus + thin on 1.9.2 on OSX as it reliably crashes every ten minutes and I have no clue on how to debug it, but it is not a problem with the interpreter, it's a problem with external libraries.

Re: The Broken Promises of MRI/REE/YARV

#69

Post by ice799 »

msbarnett wrote: post #56
Nelson69 wrote: post #55

Earlier quoted context omitted.

I kind of branded it a bit "douchey" at first too but then as I thought about it, it seemed remarkably restrained considering he debugged this issue. It's not like this happened all the time, had to get kind of lucky and build and calibrate a system just right to capture it. I don't intend this to be an inflammatory question, I'm sort of a perpetual ruby novice, it's never been my day job and I've never managed to so…

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.

Re: The Broken Promises of MRI/REE/YARV

#70

Post by strmpnk »

strmpnk wrote: post #49
rbranson wrote: post #45

Earlier quoted context omitted.

Erlang is 100% bug free. Use that instead.

You should see Joe's rants on Erlang too. Not as bad as MRI but there are plenty of things to gripe about in beam.

How does this deserve a down vote? Erlangs beam VM is pretty amazing but it's not without some pretty weird artifacts in the source, many of which I've discovered via Joe's twitter ranting.

(EDIT: I guess people don't like unpopular views at all, that's fine, long live jokes, forget the facts.)

Post reply on HN