1) Changing a compile-time constant to a Ruby variable (or global
variable) may have a performance impact.
2) If the tuning parameter is MRI-specific, how about namespacing it as
GC::MRI.heap_min_slots or GC.mri_heap_min_slots?

Martin Duerst wrote:
> At 01:24 09/01/27, Thomas Enebo wrote:
>> Martin Duerst wrote:
>>> I agree that something in this direction should be done.
>>> Garbage collection details can affect performance a lot.
>>>
>>> Exposing one or two variables isn't difficult. I'm wondering
>>> why this hasn't been done yet. One guess is that it would
>>> not at all be portable to other systems (JRuby,...).
>>>   
>> No reason MRI should not consider making their GC tunable IMHO.
> 
> I was only trying to guess reasons why this hasn't happened yet,
> and that was the only one I was able to come up with (but not a very
> good one, I agree).
> 
> Regards,   Martin.
> 
>> I think GC tunables at startup or during runtime should be considered implementation dependent.  Java has many different GCs.  Certainly not all GC's have the same tunable parameters.  Even if they did would you really expect a tunable to work on different GC impls as expected?
>>
>> If this is doable at runtime, then it would be nice if the GC API would allow a name to be associated with the parameter being tweaked so we could ignore the setting if using the wrong GC.  The name is just a random idea, but everyone should get the point...
>>
>> If it is settable at the command-line...ditto...
>>
>> -Tom
> 
> 
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst / it.aoyama.ac.jp     
> 
>