Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Don't call rb_gc_finalize_deferred "just in case".

  • Loading branch information...
commit 83fc22f0283d14d1494e43fc0694d2cd7bc11cb3 1 parent 5875c35
Evan Weaver authored
Showing with 0 additions and 2 deletions.
  1. +0 −2  eval.c
2  eval.c
@@ -5825,7 +5825,6 @@ eval_check_tick()
if ((++tick & 0xff) == 0) {
CHECK_INTS; /* better than nothing */
- rb_gc_finalize_deferred();
@@ -11419,7 +11418,6 @@ rb_thread_schedule()
rb_thread_pending = 0;
- rb_gc_finalize_deferred();
if (curr_thread == curr_thread->next
&& curr_thread->status == THREAD_RUNNABLE)

3 comments on commit 83fc22f


This longstanding Ruby bug is only triggered in REE and friends, but leads to thread corruption.

Kiji calls rb_gc_finalize_deferred() after every eden collection, so there is no reason to randomly do it during evaluation context.


This change caused the memory utilization for our spec runs to go from 1gb to 11gb. We had to back the change out because we were running out of memory.


In order to fix the threading problem, you only need to remove rb_gc_finalize_deferred() on Line#11422. Calling rb_gc_finalize_deferred() every 256 ticks helps to release memory.

Please sign in to comment.
Something went wrong with that request. Please try again.