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