Project

General

Profile

Bug #9035

Updated by nobu (Nobuyoshi Nakada) over 10 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 

Back