From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: guile-2.9.2 and threading Date: Fri, 07 Jun 2019 01:01:55 -0400 Message-ID: <87d0jqasyp.fsf@netris.org> References: <87h892ault.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="268294"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Guile User , Guile Development To: Linas Vepstas Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jun 07 07:12:34 2019 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.47]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hZ7B4-0017g7-Lg for guile-user@m.gmane.org; Fri, 07 Jun 2019 07:12:34 +0200 Original-Received: from localhost ([::1]:46004 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZ7B3-0003KU-Ne for guile-user@m.gmane.org; Fri, 07 Jun 2019 01:12:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40622) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hZ7AN-00039k-Bv for guile-user@gnu.org; Fri, 07 Jun 2019 01:11:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hZ737-0002of-F5 for guile-user@gnu.org; Fri, 07 Jun 2019 01:04:22 -0400 Original-Received: from world.peace.net ([64.112.178.59]:33824) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hZ732-000210-Md; Fri, 07 Jun 2019 01:04:18 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hZ72u-0003k5-Dg; Fri, 07 Jun 2019 01:04:08 -0400 In-Reply-To: <87h892ault.fsf@netris.org> (Mark H. Weaver's message of "Fri, 07 Jun 2019 00:26:27 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15541 gmane.lisp.guile.devel:19949 Archived-At: Mark H Weaver writes: >> Two are stuck here: >> >> #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 >> #1 0x00007f343ca69bb5 in __GI___pthread_mutex_lock ( >> mutex=mutex@entry=0x7f343d4f0f40 ) >> at ../nptl/pthread_mutex_lock.c:80 >> #2 0x00007f343d213e20 in scm_gc_register_allocation (size=size@entry=16) >> at ../../libguile/gc.c:591 > > This is the global GC allocation lock, which might be an issue if your > threads are performing a lot of heap allocation. Sorry, I spoke too quickly here, although what I wrote is not far from the truth. 'bytes_until_gc_lock' is used by Guile to protect its global counter of how much plain 'malloc' memory has been allocated since the last garbage collection. Once it reaches a certain threshold, a garbage collection is forced. Why do we have this? Sometimes the GC heap contains a large number of small collectible objects which reference much larger objects in plain 'malloc' memory. For example, this can happen if you're creating a lot of bignums, which are small GC objects pointing to digit data stored in 'malloc' memory. The garbage collector doesn't trigger because there's plenty of free memory in the GC heap, and it doesn't know that those small objects are keeping alive much larger objects elsewhere. However, if this particular lock is a pain point for you, there are things we could do to improve this. One idea that comes to mind is to keep smaller per-thread counters, which are only added to the global counter after they reach a certain threshold value. In this case, we don't need a precise global count. Mark