In defence of GVL
summary
Argues the global VM lock keeps interpreter code simpler and faster: experiments with fine-grained locks make the VM significantly slower and use more memory. Notes Python’s PEP 703 removes the GIL by using immortalization, biased reference counting, deferred refcount updates, optimistic locking and CAS, and estimates multi-year work with C-API risk. Claims most Ruby workloads are I/O-bound so GVL cost is small, and Ruby uses ractors to run CPU-bound tasks in parallel (the tarai benchmark shows near 4× speedup on multicore).
AI-written summary · about
chapters (19)
- 0:00Introduction
- 0:55What is the Global Interpreter Lock
- 2:23GIL necessity for thread safety
- 4:35Hardware evolution and concurrency
- 7:12Moore’s Law limits and multicore
- 10:31Parallelism for performance
- 11:36Removing GIL and fine-grained locks
- 14:33PEP 703 GIL removal proposal
- 16:00Reference counting without GIL
- 18:09Eliminating GIL impact strategies
- 22:09Fine-grained locks and optimistic locking
- 24:45PEP 703 feasibility concerns
- 26:13Ruby’s GIL removal need measured
- 27:40GIL less problematic for Ruby web apps
- 29:29Python vs Ruby motivation
- 31:15Introducing Ractors
- 32:18Ractors parallel performance demo
- 33:26Ruby keeps GIL for now
- 34:10Conclusion
