Feature #9761: TRY_WITH_GC with ruby_gc_stress

• Status: Closed
• Assignee: -
• Target version: -

[wanabe (_ wanabe)]

I hope TRY_WITH_GC() may use ruby_gc_stress value.

Currently, ruby_gc_stress doesn't affect simple xmalloc()/xrealloc()/xcalloc().
It is usefull to make these functions under gc-stress.
For example, #9657 is difficult to reproduce on trunk because there is not object creation but memory allocation after BigDecimal_new().

[wanabe (_ wanabe)]

• Description updated (diff)

[nobu (Nobuyoshi Nakada)]

• Description updated (diff)
• Category set to core
• Status changed from Open to Feedback

Patches are welcome.

[wanabe (_ wanabe)]

• File try_with_gc-with-gc_stress.patch try_with_gc-with-gc_stress.patch added
• Category deleted (core)
• Status changed from Feedback to Open

I have written but I have not been able to avoid both temporary assignment and duplication of garbage_collect_with_gvl().

[wanabe (_ wanabe)]

• Category set to core

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Feedback

Seems objspace_malloc_increase() already runs GC after xmalloc and xcalloc if ruby_gc_stress is set.
You may want it to run after xrealloc too?
Or to run full marking?

[wanabe (_ wanabe)]

• File xrealloc-with-gc_stress.patch xrealloc-with-gc_stress.patch added
• Status changed from Feedback to Open

Nobuyoshi Nakada wrote:

Seems objspace_malloc_increase() already runs GC after xmalloc and xcalloc if ruby_gc_stress is set.
You may want it to run after xrealloc too?
Or to run full marking?

Sorry for my poor code reading...
It is enough to add a case of xrealloc for my concern, reproducing #9657.

Anyone can close/reject this ticket if you think this is far from the original proposal.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

Applied in changeset r45653.

---

gc.c: GC.stress after realloc

• gc.c (objspace_malloc_increase): run GC after realloc not only
  malloc and calloc by GC.stress. [ruby-core:62103] [Feature #9761]

[nobu (Nobuyoshi Nakada)]

• Related to Bug #9859: An object with 6 instance variables causes SEGV added