Bug #9035
Updated by nobu (Nobuyoshi Nakada) about 11 years ago
=begin = 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 =end