Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

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
View
2  eval.c
@@ -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

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

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.