Feature #8985

xwillfree - promise to free memory

Added by Yura Sokolov almost 2 years ago. Updated almost 2 years ago.

[ruby-core:57667]
Status:Closed
Priority:Normal
Assignee:-

Description

This patch changes semantic of RUBY_GC_MALLOC_LIMIT.
Instead of being "periodical trigger" it becomes more like "safety trigger"
which fires in allocation increase (instead of allocation amount).
So that there is less need to tune RUBY_GC_MALLOC_LIMIT at all, and default
8Mb becomes meaningful.

Before GC relaxation in commit 8c0033a make check ran 13% faster
(292s instead of 338s) and doesn't seems to use more memory. It is now
runs at the same speed, but I propose to revert some part of GC
relaxation.

Tradeoffs for patch simplicity:
- it is not exact: only String, Array, Object, Struct, Bignum and Time are handled
- only one function (xwillfree) introduced. Perhaps, more readable api could be useful.
- xwillfree exposed to the public (ruby.h). Perhaps, it should be in an internal.h,
but st.c doesn't include internal.h.
And may be it could be useful for extensions.

https://github.com/ruby/ruby/pull/414
https://github.com/ruby/ruby/pull/414.patch
https://github.com/ruby/ruby/pull/414.diff

xwillfree.diff Magnifier (11.1 KB) Yura Sokolov, 10/04/2013 08:38 PM

Associated revisions

Revision 43330
Added by Koichi Sasada almost 2 years ago

  • gc.c, internal.h: add new internal memory mangement functions.
  • void *ruby_xsizedrealloc(void *ptr, size_t new_size, size_t old_size)
  • void ruby_xsizedfree(void *x, size_t size) These functions acccept additional size parameter to calculate more accurate malloc_increase parameter which control GC timing. [Feature #8985]

Revision 43330
Added by Koichi Sasada almost 2 years ago

  • gc.c, internal.h: add new internal memory mangement functions.
  • void *ruby_xsizedrealloc(void *ptr, size_t new_size, size_t old_size)
  • void ruby_xsizedfree(void *x, size_t size) These functions acccept additional size parameter to calculate more accurate malloc_increase parameter which control GC timing. [Feature #8985]

History

#1 Updated by Yura Sokolov almost 2 years ago

SASADA Koichi wrote:

Ah, it is synchronicity.

I have another idea to approach for it.

how about another version of ruby_xfree() and ruby_xrealloc() to passing
2nd argument, which is passing same information pasing to xwill_free().

ptr = xmalloc2(100); /* allocate 100 byte /
xrealloc2(ptr, 100, 200); /
reallocate 100 to 200 /
xfree2(ptr, 200); /
free 200 byte */

Doing same objective. but reduce one function call. I like this approach.

I mentioned that one function is tradeoff for patch simplicity - just for
idea presentation. And there is REALLOC_N: passing another one argument
to could look ugly in several place.

Any way, I like idea with additional argument to functions.

#2 Updated by Koichi Sasada almost 2 years ago

Ah, it is synchronicity.

I have another idea to approach for it.

how about another version of ruby_xfree() and ruby_xrealloc() to passing
2nd argument, which is passing same information pasing to xwill_free().

ptr = xmalloc2(100); /* allocate 100 byte /
xrealloc2(ptr, 100, 200); /
reallocate 100 to 200 /
xfree2(ptr, 200); /
free 200 byte */

Doing same objective. but reduce one function call. I like this approach.

(2013/10/04 20:38), funny_falcon (Yura Sokolov) wrote:

Issue #8985 has been reported by funny_falcon (Yura Sokolov).


Feature #8985: xwillfree - promise to free memory
https://bugs.ruby-lang.org/issues/8985

Author: funny_falcon (Yura Sokolov)
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: current: 2.1.0

This patch changes semantic of RUBY_GC_MALLOC_LIMIT.
Instead of being "periodical trigger" it becomes more like "safety trigger"
which fires in allocation increase (instead of allocation amount).
So that there is less need to tune RUBY_GC_MALLOC_LIMIT at all, and default
8Mb becomes meaningful.

Before GC relaxation in commit 8c0033a make check ran 13% faster
(292s instead of 338s) and doesn't seems to use more memory. It is now
runs at the same speed, but I propose to revert some part of GC
relaxation.

Tradeoffs for patch simplicity:
- it is not exact: only String, Array, Object, Struct, Bignum and Time are handled
- only one function (xwillfree) introduced. Perhaps, more readable api could be useful.
- xwillfree exposed to the public (ruby.h). Perhaps, it should be in an internal.h,
but st.c doesn't include internal.h.
And may be it could be useful for extensions.

https://github.com/ruby/ruby/pull/414
https://github.com/ruby/ruby/pull/414.patch
https://github.com/ruby/ruby/pull/414.diff

--
// SASADA Koichi at atdot dot net

#3 Updated by Koichi Sasada almost 2 years ago

(2013/10/04 21:30), SASADA Koichi wrote:

Ah, it is synchronicity.

because we Heroku ruby team discussing about xfree2 and xrealloc2.

ptr = xmalloc2(100); /* allocate 100 byte */

Sorry. We don't need xmalloc2().

--
// SASADA Koichi at atdot dot net

#4 Updated by Koichi Sasada almost 2 years ago

(2013/10/04 21:38), funny_falcon (Yura Sokolov) wrote:

Any way, I like idea with additional argument to functions.

One more advantage of additional argument is we can verify passed size
argument with CALC_EXACT_MALLOC_SIZE option in gc.c.

--
// SASADA Koichi at atdot dot net

#5 Updated by Koichi Sasada almost 2 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r43330.
Yura, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • gc.c, internal.h: add new internal memory mangement functions.
  • void *ruby_xsizedrealloc(void *ptr, size_t new_size, size_t old_size)
  • void ruby_xsizedfree(void *x, size_t size) These functions acccept additional size parameter to calculate more accurate malloc_increase parameter which control GC timing. [Feature #8985]

Also available in: Atom PDF