New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xwillfree - promise to free memory #414

Closed
wants to merge 2 commits into
base: trunk
from

Conversation

2 participants
@funny-falcon

funny-falcon commented Oct 4, 2013

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 (in a second commit).

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 .
    But may be it could be useful for extensions.

Issue http://bugs.ruby-lang.org/issues/8985

funny-falcon added some commits Oct 4, 2013

xwillfree - promise to free memory
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 (in a next commit).

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 .
  But may be it could be useful for extensions.
revert GC_MALLOC_LIMIT_MAX relaxation and not collecting on realloc
they are not such useful if xwillfree accepted
@hsbt

This comment has been minimized.

Show comment
Hide comment
@hsbt
Member

hsbt commented Nov 4, 2014

This issue is solved by https://bugs.ruby-lang.org/issues/8985

@hsbt hsbt closed this Nov 4, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment