Bug #9035

Updated by Nobuyoshi Nakada over 2 years ago

= Background

Currently, whenever the Ruby GC runs out of object slots the heap is grown by 1.8x (((%GC_HEAP_GROWTH_FACTOR%))). (GC_HEAP_GROWTH_FACTOR).
This works well for small programs, but given a large application it will cause rapid increase in memory.
For example, if a ruby program is using 1 million objects and runs out of slots, it will grow to 1.8 million objects.
This is a huge increase.

= Proposal

Introduce ((%RUBY_GC_HEAP_GROWTH_MAX_OBJ%)) RUBY_GC_HEAP_GROWTH_MAX_OBJ to avoid exponential growth in larger ruby applications.
After this limit is reached, heap growth will happen linearly instead of exponentially.
For example, if ((%growth_max=100k%)) growth_max=100k then the application above will grow from 1mm objects to 1.1mm objects.

= Discussion

((%RUBY_GC_HEAP_GROWTH_MAX%)) RUBY_GC_HEAP_GROWTH_MAX can be represented either in a) bytesize, or b) number of objects.

Arguments for (a)
* - more user friendly, since users are exposed primarily to RSS and want to control final RSS value
* - a bytesize based formula can include more varibles, for example the size of bitmaps associated with each (({RVALUE})) RVALUE

Arguments for (b)
* - consistent with existing tuning parameters (all object based, i.e. RUBY_HEAP_MIN_SLOTS)
* - GC tuning already requires measuring "startup objects", "objects per request", so object based is more friendly
* - bytesize is confusing because ((%GROWTH_MAX%)) GROWTH_MAX only controls growth of ruby heap, not total RSS
* - this is an advanced feature meant for use by experts (default value will be 0 = no change from behavior)
since experts will be using it, we can assume they have already measured the number of objects in their ruby app first