Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Ruby 2.7 introduced GC compaction, a way to reduce memory memory usage in your application. Unfortunately the compaction process is completely manual, requiring developers to determine the best time to compact their heap. This talk is about making the compaction process automatic and the challenges in doing so. We'll discuss various implementation techniques including read barriers and running the GC concurrently with the main program. This talk will have read barriers, but it won't have watch barriers, so come watch the talk! Aaron Patterson Aaron is a full time Ruby developer working at Shopify, whose interests include: Keyboards, Cats, and Code. Aaron is known online as tenderlove, but he also answers by "Aaron".
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
This presentation by Aaron Patterson, known online as Tenderlove, at RubyConf 2020 focuses on the topic of automatic GC (Garbage Collection) compaction in Ruby, particularly as it will be implemented in Ruby 3.0. The primary goal is to automate the memory compaction process, which was introduced in Ruby 2.7 through manual calls to `GC.compact`, allowing developers to save memory by eliminating fragmentation in the application’s heap. Key Points Discussed: - **Introduction to GC Compaction**: Aaron explains how Ruby 2.7's feature, `GC.compact`, operates similarly to the defrag utility in MS-DOS by reorganizing memory to reduce fragmentation. - **Compaction Process**: The process involves moving live objects to fill empty slots in the heap and requires updating references to moved objects afterward. - **Goals for Ruby 3.0**: The focus is on three main aims: - **Memory Savings**: Achieving a narrower heap representation without changing the number of objects, leading to lower memory usage. - **Automation**: Developers should not need to manually invoke compaction; it should happen seamlessly in the background. - **Concurrency**: Enabling the compaction process to run concurrently with other processes to enhance speed and reduce program pauses. - **Challenges**: The complexity arises from needing to ensure that object references remain valid during the compaction while the garbage collector must work in a strict order. - **Proposed Solutions**: Aaron shares his plan for concurrent execution of the sweeping and moving phases of the garbage collection process. This includes the introduction of read barriers and considerations like using the `mprotect` call to handle memory access violations after compaction. - **Real-World Testing**: Aaron discusses the rigorous testing and benchmarks conducted which illustrated improved memory utilization with new patches and their implications for overall program performance. Conclusion: The implementation of automatic GC compaction in Ruby 3.0 has notable potential to improve memory management, reduce the need for manual intervention by developers, and enhance application performance. Aaron encourages the audience to explore these new enhancements in the upcoming Ruby 3.0 release, emphasizing the importance of understanding memory management mechanisms to foster improvements in programming practices.
Suggest modifications
Cancel
