4 ms·

fork() in Ruby would be much better if MRI's garbage collector wasn't so awful -- because it marks every reachable object in each collection cycle, it's impossi

by blasdel 17y ago

fork() in Ruby would be much better if MRI's garbage collector wasn't so awful -- because it marks every reachable object in each collection cycle, it's impossible for MRI processes to take advantage of the kernel's copy-on-write memory sharing post-fork. You can't even just let the processes gobble up space and let the kernel's VM sort it out -- anything that gets swapped out will have to be paged back in to be marked by the GC. Churn.

jwinter 17y ago
Right, that's exactly what Ruby EE was written to solve. Would've been nice for that to land in Ruby 1.9, but at least REE exists.
defunkt 17y ago
But if you're already taking that memory hit with separate processes, ala mongrel cluster, fork() still provides a number of juicy advantages (which the article explains).
pdubroy 17y ago
I'm not familiar with the MRI source, but in most collectors, I'd think that switching from marking the object directly to using a separate mark map should be pretty trivial (like an afternoon's work). You'd still have to copy the pages for the mark map as soon as you GC in the child process, but that's only 3% of your total heap size.
- steveklabnik 17y ago
  The thing is, (from what I understand) Matz isn't interested in performance, he's interested in the language. This is why YARV is Ruby 1.9. So even if it took an afternoon, there'd be no reason to use it, as MRI is the past anyway. (and for those of us still using 1.8.x, there's REE)
boulderdash 17y ago
almost all GCs are awful
- boulderdash 17y ago
  actually, in this day and age... if you hit disk for paging/swap on a production server... "you are doing it wrong"... this should not be an issue
- stcredzero 17y ago
  almost all GCs are awful Wrong -- almost all of the most visible GCs in the most popular languages are either 1) still awful or 2) were formerly awful for such a long time, they're still living it down. It's a vicious cycle. - GCs have a bad rep. - Precocious programmer implementes their own dynamic language. - They settle for Mark/Sweep or ref counts to "get it done" (Hey, GCs are all awful anyhow, yeah?) - Many people experience the awfulness. - GCs have a bad rep -- REPEAT Chicken & egg? GCs were bad. Experts have since figured out how to make them good. The programmer culture in general is slowly getting this knowledge by diffusion. The VisualWorks GC is so good, as a lark, I once put an infinite loop into the app I was working on that did nothing but instantiate new objects. I could barely tell it was there!
  - boulderdash 17y ago
    so the 'almost all' in my above is wrong? you basically said what I said, but with your favorite smalltalk GC.
    - stcredzero 17y ago
      Yes, the GCs you've heard of constitutes an encyclopedic listing of them. </sarcasm> Hmmm, you just gave me an idea. Interview question to see if prospect knows what he doesn't know. Does she/he even have the order of magnitude right on that?

by blasdel 17y ago

jwinter 17y ago

Right, that's exactly what Ruby EE was written to solve. Would've been nice for that to land in Ruby 1.9, but at least REE exists.

defunkt 17y ago

But if you're already taking that memory hit with separate processes, ala mongrel cluster, fork() still provides a number of juicy advantages (which the article explains).

pdubroy 17y ago

I'm not familiar with the MRI source, but in most collectors, I'd think that switching from marking the object directly to using a separate mark map should be pretty trivial (like an afternoon's work). You'd still have to copy the pages for the mark map as soon as you GC in the child process, but that's only 3% of your total heap size.

steveklabnik 17y ago
The thing is, (from what I understand) Matz isn't interested in performance, he's interested in the language. This is why YARV is Ruby 1.9. So even if it took an afternoon, there'd be no reason to use it, as MRI is the past anyway. (and for those of us still using 1.8.x, there's REE)

boulderdash 17y ago

almost all GCs are awful

boulderdash 17y ago
actually, in this day and age... if you hit disk for paging/swap on a production server... "you are doing it wrong"... this should not be an issue
stcredzero 17y ago
almost all GCs are awful Wrong -- almost all of the most visible GCs in the most popular languages are either 1) still awful or 2) were formerly awful for such a long time, they're still living it down. It's a vicious cycle. - GCs have a bad rep. - Precocious programmer implementes their own dynamic language. - They settle for Mark/Sweep or ref counts to "get it done" (Hey, GCs are all awful anyhow, yeah?) - Many people experience the awfulness. - GCs have a bad rep -- REPEAT Chicken & egg? GCs were bad. Experts have since figured out how to make them good. The programmer culture in general is slowly getting this knowledge by diffusion. The VisualWorks GC is so good, as a lark, I once put an infinite loop into the app I was working on that did nothing but instantiate new objects. I could barely tell it was there!
- boulderdash 17y ago
  so the 'almost all' in my above is wrong? you basically said what I said, but with your favorite smalltalk GC.
  - stcredzero 17y ago
    Yes, the GCs you've heard of constitutes an encyclopedic listing of them. </sarcasm> Hmmm, you just gave me an idea. Interview question to see if prospect knows what he doesn't know. Does she/he even have the order of magnitude right on that?