From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 4390D17D6269 for ; Sat, 15 Mar 2014 16:18:40 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id AB404B5DB01 for ; Sat, 15 Mar 2014 16:15:38 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 7F86F97A82C for ; Sat, 15 Mar 2014 16:15:40 +0900 (JST) X-Virus-Scanned: amavisd-new at nagaokaut.ac.jp Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHBTKFmoVlqu for ; Sat, 15 Mar 2014 16:15:40 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 5F4EF97A82B for ; Sat, 15 Mar 2014 16:15:40 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id 6DB8B95241A for ; Sat, 15 Mar 2014 16:15:38 +0900 (JST) Received: from [221.186.184.76] (unknown [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D86D512081F; Sat, 15 Mar 2014 16:15:35 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from sakura2.atdot.net (www4150ue.sakura.ne.jp [219.94.244.164]) by neon.ruby-lang.org (Postfix) with ESMTP id 7A7EE1207F4 for ; Sat, 15 Mar 2014 16:15:28 +0900 (JST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by sakura2.atdot.net (Postfix) with ESMTP id EDFF811838B; Sat, 15 Mar 2014 16:15:27 +0900 (JST) Message-ID: <5323FE11.3000908@atdot.net> Date: Sat, 15 Mar 2014 16:15:29 +0900 From: SASADA Koichi User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ruby-core@ruby-lang.org References: <20140312000622.GA7155@dcvr.yhbt.net> <5321B2CA.60104@atdot.net> <20140313171243.GA10468@dcvr.yhbt.net> In-Reply-To: <20140313171243.GA10468@dcvr.yhbt.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ML-Name: ruby-core X-Mail-Count: 61508 Subject: [ruby-core:61508] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" (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. >> > # 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. BTW, > + rb_thread_t *th = ruby_thread_from_native(); `th' can be NULL because no Ruby threads can call this code. -- // SASADA Koichi at atdot dot net