Bug #18014
closed
Memory leak in GC when using Ractors
Description
GitHub PR: https://github.com/ruby/ruby/pull/4613
When a Ractor is removed, the freelist in the Ractor cache is not returned to the GC, leaving the freelist permanently lost.
The following script demonstrates the issue. It iterates 2000 times, in each iteration it simply creates a new Ractor that creates a new object. It stores the objects in an array in the main thread to prevent the object from being GC'd. This is important as if the object is GC'd the heap page will be freed if the whole page is empty.
arr = []
2000.times do
# Start new Ractor that creates a new object
arr << Ractor.new { Object.new }.take
puts GC.stat(:heap_allocated_pages)
end
We can now graph the output from master and the branch with the patch.
We can see that the Ractor implementation creates heap pages linearly with the number of iterations. On my machine, this script on master uses about 43MB of memory while the patched version uses 13MB.
This is because when a new heap page is created (with 409 empty slots), the Ractor uses the page to allocate a single object, and leaks the remaining slots (408 slots).
Patch¶
The patch recycles the freelist when the Ractor is destroyed, preventing a memory leak from occurring.
An assertion has been added after gc_page_sweep to verify that the freelist length is equal to the number of free slots in the page.
Updated by 
Updated by