Garbage Collection for Ractors

The fork of Ruby that I developed this project in can be found here: https://github.com/rm155/ruby/tree/Ractor-Local-GC-version-1

Background

Ruby 3.0 introduced Ractors, a feature that enables true concurrency in the language. By allowing different pieces of code to run at the same time, the execution time of program can be greatly reduced. However, when multiple processes work on the same data concurrently, it can lead to data race conditions, which cause the program to behave unpredictably. Because of this, Ruby heavily restricts the use of shared data between Ractors.

In my 2021 GSoC project, I helped modify existing Ruby libraries to be compliant with Ractor rules. The purpose of this was to make the functionality of those libraries usable within Ractors. After the project, I continued to work with Ractors, and I found that Ractors were not providing as much of a speedup as one might have expected. I a

Ractor-Supported Libraries

Objective

Ruby 3 introduced Ractors, which are a mechanism for concurrency. However, in order to ensure that the concurrency does not create conflicts, Ractors impose constraints on the code. In particular, they limit the usage of variables that might otherwise allow for data races among Ractors. For example, class variables and class instance variables cannot be used within Ractors.

There are many existing libraries that currently rely on code that is incompatible with Ractors. Consequently, these libraries have features that cannot be used within Ractors. This prevents users from taking full advantage of the concurrency provided by Ractors. The objective of this project was to modify Ruby’s standard libraries so that they comply to the restrictions of Ractors. Ideally, this would allow users writing code in Ractors to freely utilize most features in Ruby’s standard libraries.

Approach

For each library, it had to be determined as to whether or not the library contained R