The Practical Effects of the GVL on Scaling in Ruby

The Global Virtual Machine Lock confuses many Rubyists. Most Rubyists I’ve met have a vague sense that the GVL is somehow bad, and has something to do concurrency or parallelism.‘CRuby’ refers to the mainline Ruby implementation, written in C. Sometimes people call this ‘MRI’.The GVL (formerly known as GIL, as you’re about to learn) is a unique feature to CRuby, and doesn’t exist in JRuby or TruffleRuby.JavaScript’s popular V8 virtual machine also has a VM lock. CPython also has a global VM lock. That’s three of the most popular dynamic languages in the world! VM locks in dynamic languages are very common.Instead of removing the GVL, Ruby core has signaled that it will take an approach similar to V8 Isolates with inspiration from the Actor concurrency model (discussed at the end).Understanding CRuby’s Global VM Lock is important when thinking about scaling Ruby applications. It will probably never be removed from CRuby completely, and its behavior changes how we scale Ruby apps efficiently.Understanding what the GVL is and why the current GVL is “global” will help you to answer questions like these:What should I set my Sidekiq concurrency to?How many threads should I use with Puma?Should I switch to Puma or Sidekiq from Unicorn, Resque, or DelayedJob?What are the advantages of event-driven concurrency models, like Node?What are the advantages of a global-lock-less language VM, like Erlang’s BEAM or Java’s JVM?How will Ruby’s concurrency story change in Ruby 3?We’ll deal with these questions and more in this article.