Permalink
Browse files

Don't call rb_gc_finalize_deferred "just in case".

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

3 comments on commit 83fc22f

@evan
evan commented on 83fc22f Jul 29, 2011

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.

@shr3kst3r

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.

@Chehai
Chehai commented on 83fc22f Apr 10, 2012

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.