Feature #1047

request: getters, setters for the GC

Added by Roger Pack over 6 years ago. Updated about 3 years ago.

[ruby-core:21552]
Status:Closed
Priority:Normal
Assignee:Narihiro Nakamura

Description

=begin
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
=end

1047.patch Magnifier - Patch for issue #1047. (3.51 KB) Michael Edgar, 03/05/2010 05:10 AM

bm_hilbert_matrix.rb Magnifier (682 Bytes) Roger Pack, 03/20/2010 01:45 AM

patch-1.9.2-gc.patch Magnifier - patch for setting GC parameters from environment variables (3.32 KB) Yura Sokolov, 03/06/2011 04:38 PM

patch-1.9.2-gc-methods.patch Magnifier - patch for GC parameters getters and setters (3.21 KB) Yura Sokolov, 03/06/2011 06:07 PM

patch-1.9.2-gc-methods.patch Magnifier - patch for GC parameters getters and setters (3.21 KB) Yura Sokolov, 03/06/2011 06:08 PM

History

#1 Updated by Martin Dürst about 6 years ago

=begin
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:

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


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

=end

#2 Updated by Martin Dürst about 6 years ago

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

=end

#3 Updated by Charles Nutter about 6 years ago

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

=end

#4 Updated by Koichi Sasada about 6 years ago

  • Assignee set to Narihiro Nakamura

=begin

=end

#5 Updated by Michael Edgar about 5 years ago

=begin
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.
=end

#6 Updated by Yusuke Endoh about 5 years ago

  • Status changed from Open to Feedback
  • Target version set to 2.0.0

=begin
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
=end

#7 Updated by Kornelius Kalnbach about 5 years ago

=begin
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]

=end

#8 Updated by Charles Nutter about 5 years ago

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

=end

#9 Updated by Roger Pack about 5 years ago

=begin
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 N2 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.
=end

#10 Updated by Yusuke Endoh about 5 years ago

=begin
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.

--
Yusuke ENDOH mame@tsg.ne.jp

=end

#11 Updated by Yura Sokolov about 4 years ago

=begin
May be we could accept method from railsbench - setting such variables from environment?
It is up to system administrator running ruby server to set them to adequate value.

This approach works well for REE.

Attached patch also is here https://gist.github.com/856296

Or combine them.
After all, programmer always could do "GC.respond_to?(:malloc_limit=)"

PS. GC.free_min= is useful also.
=end

#12 Updated by Yura Sokolov about 4 years ago

=begin
I adapt 1047.patch to be applied after patch-1.9.2-gc.patch .

Changes:
* renamed GC.heap_slots and GC.heap_slots= to GC.heap_min_slots and GC.heap_min_slots=
* add GC.free_min and GC.free_min=
=end

#13 Updated by Yura Sokolov about 4 years ago

=begin
Sorry for double post :(
=end

#14 Updated by Narihiro Nakamura about 4 years ago

=begin
Hi.

I think this patch depend too much on inside implementation of MRI.
So, I can't agree this patch...

Thanks.
=end

#15 Updated by Yukihiro Matsumoto about 4 years ago

=begin
Hi,

Well then, how do you think we can accomplish this performance
improving without depending too much on MRI internals.

I myself think configuration via environment variables or command line
options can rely on internals.

                        matz.

In message "Re: [Ruby 1.9 - Feature #1047] request: getters, setters for the GC"
on Mon, 7 Mar 2011 11:11:13 +0900, Narihiro Nakamura authorNari@gmail.com writes:

|Hi.
|
|I think this patch depend too much on inside implementation of MRI.
|So, I can't agree this patch...
|
|
|Thanks.
=end

#16 Updated by Narihiro Nakamura about 4 years ago

=begin
Hi,

2011/3/7 Yukihiro Matsumoto matz@ruby-lang.org:

Hi,

Well then, how do you think we can accomplish this performance
improving without depending too much on MRI internals.

I myself think configuration via environment variables or command line
options can rely on internals.

OK. I intend to think about specifications in reference to this patch.

Thanks.
--
Narihiro Nakamura (nari)
=end

#17 Updated by Roger Pack about 4 years ago

=begin
I think the desired goal is a "user configurable" GC, whatever that may mean finally (I'm ok with direct internals).
Cheers!
-r
=end

#18 Updated by Yusuke Endoh about 3 years ago

Nari, any update on this?

Yusuke Endoh mame@tsg.ne.jp

#19 Updated by Narihiro Nakamura about 3 years ago

  • Status changed from Assigned to Closed

We have introduced the GC parameter configuration to trunk at r31044.

Thanks.

Also available in: Atom PDF