From: nagachika00@... Date: 2021-07-22T02:48:49+00:00 Subject: [ruby-core:104659] [Ruby master Bug#18014] Memory leak in GC when using Ractors Issue #18014 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED to 2.6: DONTNEED, 2.7: DONTNEED, 3.0: DONE ruby_3_0 a215c6d0448764131cbbb48b476dc698b51c2273 merged revision(s) 119697f61e2b2b157816a8aa33aada5863959900,4a627dbdfd1165022fa9e716ba845e937b03773d. ---------------------------------------- Bug #18014: Memory leak in GC when using Ractors https://bugs.ruby-lang.org/issues/18014#change-92970 * Author: peterzhu2118 (Peter Zhu) * Status: Closed * Priority: Normal * Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: DONE ---------------------------------------- # 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. ```ruby 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. ![](https://user-images.githubusercontent.com/15860699/123850597-3a79b880-d8e8-11eb-8b0c-45379304b159.png) 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. -- https://bugs.ruby-lang.org/ Unsubscribe: