From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Wed, 25 Dec 2024 17:03:08 +0000 Message-ID: <87jzbn8zmu.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <87y104aih6.fsf@protonmail.com> <87ikr89gyp.fsf@protonmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36559"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 18:24:37 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tQV7d-0009NC-Am for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 18:24:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQV7L-0000DE-2g; Wed, 25 Dec 2024 12:24:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQUmz-00042t-Tf for emacs-devel@gnu.org; Wed, 25 Dec 2024 12:03:18 -0500 Original-Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQUmy-0004xH-08; Wed, 25 Dec 2024 12:03:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735146193; x=1735405393; bh=Pc6J8/OKQQ+fGsXuh2f33JspU+m+MG4vMyS7dKyqVAU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=ziwsvbK4iQ5FriUut0siszgr7uBWcXRcAGNauPflWzm+KctPtzyVLE6Z9SvNzV2HW X2g2W+ApjdJg+DZQGKtSQNNPsQjZTIpBGVPIMV0nue3d2Vr3MpN42idT3uFrY55+wx lVHLahLH09eN8XmzEPp0I9nSDTBWe0mQdCylXhSpCj0NiOZL6vtlPoeU+cNZC8G3cp i6p7UiM2L7iMRkDjyhkepE5n4tultUBizzWY1WuqKt1zFkfHdU6LT3rSfz6IDXH5vO TRAGdec5mgb79mU+EhqwYnkuSEnyEY6/BLkEK46HC0MgGZDSQalH6cViWCBXrAOTx6 DE0dGeKJLhIww== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: f784bf22b3b3d22100199dd3a4687837e3f9f51d Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 25 Dec 2024 12:24:11 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327113 Archived-At: "Stefan Kangas" writes: > Pip Cet via "Emacs development discussions." > writes: > >>> I think that's already true for the old GC. There is nothing >>> guaranteeing that the contents of the binding stack is consistent, for >>> example. But we get away with it well enough that the profiler is >>> useful. >> >> My understanding is that was true at one point, before C caught up to >> memory ordering between a thread and its signal handlers, but with C11, >> we have everything we need to ensure consistency, at least on systems >> that store words atomically (we don't use memcpy for modifying the >> specpdl stack). > > Which parts of C11 help us? stdatomic.h, in this case. Please take the rest of this email with a grain of salt: as far as I know, compilers and I have reached the promised land of explicit memory barriers, and I'm actively trying to forget about the precise rules surrounding implicit memory barriers in the old days. The summary is we should explicitly indicate thread/signal data dependencies (atomic_signal_fence) in new or modified code, and explicitly indicate thread/thread dependencies in new code (atomic_thread_fence). If the compiler doesn't support it, we must assume it's too old to reorder stores. https://github.com/rmind/stdc/blob/master/c11memfences.md seems to mostly agree with my memory, though. IIRC, C99 doesn't have usable memory barriers, not even for signal handler/main thread races such as this one. Of course almost every compiler that supports C99, and certainly all compilers usable for compiling Emacs, provides (or doesn't need, in the case of TinyCC) ways of implementing them. In the case of GCC, that used to be asm volatile ("" : : : "memory"). > I'm probably missing something obvious, but aren't we using C99 on the > scratch/igc branch also? We're using C99 + a lot of assumptions (most importantly, conservative scanning lore). If my memory is correct, this particular assumption (as far as the compiler goes) changed from "C won't reorder stores" to "C won't reorder stores across a non-inlined function" (where "non-inlined" changed from "not explicitly inlined", then "in another CU so it can't be inlined", then to "explicitly defined as non-inlined"), and finally to "you have to tell C explicitly not to reorder stores". Emacs hasn't caught up with the final change, so we're currently in a "nothing guarantees that it'll work, but it kind of does" stage with regard to the specpdl and profiling. Very old compilers don't support or require explicit memory barriers; old compilers support but don't require them; current/future compilers may require them. Note that Gerd appeared to be disagreeing about some part of this, but I'm not sure which part precisely. Pip