Forum: Ruby-core [Feature #1047] request: getters, setters for the GC

Feature #1047: request: getters, setters for the GC
http://redmine.ruby-lang.org/issues/show/1047

Author: Roger Pack
Status: Open, Priority: Normal

It has been shown that increasing the malloc_limit can have a dramatic 
effect in speeding up certain programs.
ex:

Ruby 1.9 normal:
real-world/bm_hilbert_matrix.rb,
4.0054624080658,4.09904861450195,4.052255511283875,0.046793103218079,50

ruby 1.9 trunk with increased malloc_limit [1]
real-world/bm_hilbert_matrix.rb,
2.87246918678284,2.8920271396637,2.882248163223267,0.009778976440430,50

So I would like to request getters and setters for malloc_limit, 
HEAP_MIN_SLOTS, etc, if that's possible.
Thanks much!
-=r

[1] 
http://groups.google.com/group/ruby-benchmark-suite/browse_thread/thread/f56b4335cfd3ec57

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,...).

Regards,    Martin.

At 05:46 09/01/25, you wrote:
>Ruby 1.9 normal: 
>-=r
>
>[1] 
>http://groups.google.com/group/ruby-benchmark-suite/browse_thread/thread/f56b4335cfd3ec57
>
>
>----------------------------------------
>http://redmine.ruby-lang.org


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp

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 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

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

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?

Kurt,

I now use code like this:

  GC.limit=200000 if GC.respond_to? :limit

All we have to do is make an effort to ensure that GC.limit= always
does the same thing if GC responds to it.

- brent

Thomas Enebo wrote:
> No reason MRI should not consider making their GC tunable IMHO.
> 
> 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?

I'd expand this to point out that all Java's GCs have many, many
possible settings as well, but almost all are configured at startup.
There are very few settings that can be tweaked at runtime, for a couple
reasons:

* Hotspot makes some decisions about how to allocate and reallocate heap
space immediately at startup.
* Hotspot also adjust GC settings (heap ratios, tenuring rates, etc)
based on runtime information. So tweaking things at runtime would be
forcing profiled settings to be thrown out.

But in general, having some set of command-line configurable settings
would be a great idea, if it could be done without a performance impact.
JRuby users are becoming more accustomed to having many available config
settings when they need them.

- Charlie

Issue #1047 has been updated by Michael Edgar.

File 1047.patch added

I've attached a patch adding getters and setters for HEAP_MIN_SLOTS and 
GC_MALLOC_LIMIT.  All tests still pass, and the ruby-benchmark-suite 
shows no slowdown.

It works by simply adding two extra static variables that is initially 
defined to the currently-existing constants, and using that instead of 
the compile-time constants throughout the code. I then add getters and 
setters retrieve and modify those variables.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1047

Issue #1047 has been updated by Yusuke Endoh.

Status changed from Open to Feedback
Target version set to 1.9.x

Hi,

> I've attached a patch adding getters and setters for HEAP_MIN_SLOTS and GC_MALLOC_LIMIT.


My personal opinions:

- Though I think a few rough "modes" is acceptable (e.g., -server and
  -clients of Java), such a specific parameter tuning is not Ruby way.

- The name `malloc_limit' is very arguable because it is too specific
  to implementation-detail of MRI.

- HEAP_MIN_SLOTS is just referred when the interpreter is initialized.
  So I guess dynamic change of HEAP_MIN_SLOTS makes no sense.

- I cannot reproduce performance improvement as shown by Roger. Could
  you show me a self-contained code to run benchmark?

Thanks,

--
Yusuke Endoh <mame@tsg.ne.jp>
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1047

On 18.03.10 13:16, Yusuke Endoh wrote:
> My personal opinions:
> 
> - Though I think a few rough "modes" is acceptable (e.g., -server and
>   -clients of Java), such a specific parameter tuning is not Ruby way.
But it may be the only viable way to provide GC options independent of
the Ruby implementation. HEAP_MIN_SLOTS is also an implementation detail
(I think).

Another way would be to mimic --server and --client on MRI in a way that
optimizes the GC as expected (--client optimizes for startup speed and
code running once, --server optimizes for long-running and background
processes).

[murphy]

On Thu, Mar 18, 2010 at 7:16 AM, Yusuke Endoh <redmine@ruby-lang.org> 
wrote:
> - The name `malloc_limit' is very arguable because it is too specific
>  to implementation-detail of MRI.

I really hope we would not start to see a bunch of libraries or
frameworks setting things like "malloc_limit". You probably worry the
same thing.

> - HEAP_MIN_SLOTS is just referred when the interpreter is initialized.
>  So I guess dynamic change of HEAP_MIN_SLOTS makes no sense.

FWIW, on the JVM, most of the GC tunable settings must be set on
startup as well.

- Charlie

Issue #1047 has been updated by Roger Pack.

File bm_hilbert_matrix.rb added
Status changed from Feedback to Assigned

Attaching demo file.
A little contrived still, but on my box, the things that help it improve 
are (believe it or not)

-#define HEAP_MIN_SLOTS 10000
+#define HEAP_MIN_SLOTS 100000

12.3s normal gc.c

to 10.4s

Perhaps defining more space up front makes it not use N^2 garbage 
traversals as it grows?  It appears that's useful when you know you're 
going to be needing the space eventually anyway...in reality you could 
also put it as the default and it wouldn't hurt "small scripts" too much 
either, I'd imagine.

changing MALLOC_LIMIT has been shown effective in rails apps though I 
don't have any immediate numbers handy [1]

As a side note, with 1.9.1 (default) it takes 14.8s, so some improvement 
already--thanks guys!

If we do eventually go to a --server --client model, --server could 
include some other optimizations, too, like lookup cacheing

http://redmine.ruby-lang.org/issues/show/641

While we're on the subject of GC optimization, you might be some speedup 
by making gc_stress settings only available if GC_DEBUG is defined--I 
highly doubt gc_stress is used much in the wild, though I could be 
proven wrong.

Cheers!
-rp

[1] http://blog.evanweaver.com/articles/2009/04/09/ruby-gc-tuning/ 
"speedup of 34% " for 1.8 with similar settings.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1047

>> I've attached a patch adding getters and setters for HEAP_MIN_SLOTS and GC_MALLOC_LIMIT.
>
>
> My personal opinions:
>
> - Though I think a few rough "modes" is acceptable (e.g., -server and
>  -clients of Java), such a specific parameter tuning is not Ruby way.

That seems reasonable.  Maybe like --conservative or --server or what 
not.


> - The name `malloc_limit' is very arguable because it is too specific
>  to implementation-detail of MRI.

agreed.

-rp

Hi,

2010/3/20 Roger Pack <redmine@ruby-lang.org>:
> A little contrived still, but on my box, the things that help it improve are (believe it or not)
>
> -#define HEAP_MIN_SLOTS 10000
> +#define HEAP_MIN_SLOTS 100000
>
> 12.3s normal gc.c
>
> to 10.4s


Thanks.  24.2s -> 16.5s on my environment.

I actually tried with ruby-benchmark-suite and Michael's patch.
But I couldn't confirm improvement by setting GC.malloc_limit.  Now
I'm sure that in this case, the performance improvement seems to be
achieved by changing HEAP_MIN_SLOTS, rather than MALLOC_LIMIT.


> If we do eventually go to a --server --client model, --server could include some other optimizations, too, like lookup cacheing

Note that the model is *just my opinion* :-)

I even know some committers dislike such a performance configuration.
I don't know matz's opinion, but I expect him to dislike too.

>> My personal opinions:
>>
>> - Though I think a few rough "modes" is acceptable (e.g., -server and
>>  -clients of Java), such a specific parameter tuning is not Ruby way.


Here are a couple of options:

parameter flags, like
 --gc_often
 --gc_seldom

or
GC.gc_often!
GC.gc_seldom!

(or whatever verbs you want to use).

My own preference would be to still have access to the guts of the GC
during runtime--even if it's very implementation specific it would
still be useful, I think, in some cases, to have access.  Maybe
there's a way to make it more clear that they're implementation
specific, like putting them under RubyVM?

Thoughts?
-rp