[ruby-core:61509] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals

[Eric Wong <normalperson@yhbt.net>]

SASADA Koichi <ko1@atdot.net> wrote:
> (2014/03/14 2:12), Eric Wong wrote:
> > How about only using thread local and remove the process-wide globals?
> 
> I doubt
> 
> > Underflow from race conditions might cause too many GC runs.
> 
> Let the counter(s) change addition only.
> 
> separate then into:
>   malloc_increase (increase only)
>   free_increase   (increase only)
> 
> and use like that:
>   if (malloc_incraese > free_increase &&
>       malloc_incraese - free_increase > malloc_limit) {
>     do_gc();
>   }
> 
> There are no underflow.
> 
> In fact, I started this strategy just before releasing 2.1. However,
> "free_increase" is bigger than malloc_increase.  Maybe this is someone's
> bug (for example, xfree for a malloced block) or my misunderstanding.

That probably works since it's a fuzzy hint counter anyways.

You may have hit xcalloc having no increase:
http://bogomips.org/ruby.git/patch?id=08fc03c25615
(maybe malloc_usable_size is broken on some systems w/ calloc ...)

> >> > # basically, GVL protects multi-threads parallel update of such values.
> >> > # this atomic operations only for call_without_gvl().
> >> > # so it is minor case.
> > Right.  I am looking into using GVL less :)
> > For example, much of sweep phase may be done without GVL.
> 
> I see. It is problem.
> 
> # But parallel sweep on my exepriment doesn't show impressive speedup.

:<   Were there also regressions?

I wonder if the speedup would be bigger if we use an allocator with
good MT scalability.

> BTW,
> 
> > +    rb_thread_t *th = ruby_thread_from_native();
> 
> `th' can be NULL because no Ruby threads can call this code.

Did you mean: gsub(/no Ruby/, "non-Ruby") ?
I should put a FATAL exit there (but not much different than crashing).