From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Wed, 25 Dec 2024 14:31:25 +0200 Message-ID: <86ikr80wrm.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <87y104aih6.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6852"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 13:32:49 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 1tQQZF-0001bQ-Lh for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 13:32:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQQYX-0000UL-Nj; Wed, 25 Dec 2024 07:32:05 -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 1tQQYS-0000Tb-Ok for emacs-devel@gnu.org; Wed, 25 Dec 2024 07:32:02 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQQYR-0001Xv-Mx; Wed, 25 Dec 2024 07:31:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pzFxhZdZVtTxm2mvujTzKDkiXsVHlPB4oAoSo5hqkf0=; b=T313G+R9GDYDsaqgYUXe TzpS+DTPiPMxfEc5/ud4T0vy83ou0yL5FgUF6agJbx6oo45xMR4BV26gBNxyhigbQBFYI4jawEqzz QpNYcA4OwnGWB0qqws9hc7x1BWpPJE6H2EpfNtjnCfjyqoSURJgySEQCAqshdK4XJpjOkiUHF/OxB 5z3qi/wLWYcy4PM+zbo2z4LlJKPnqpShaJ8dP3YBSFDWDeSJ7Ky7/Cw+qmvaZJCRd7xkgthaH3fOV tPtR7PmwCebzsYZ4mrYJKGVOQWcGmA6nmC/ScwvMOR20TfKBBnOYwdBxQv81KoRPT5KmKfXMj2Cw2 hWNS89mU/shiGA==; In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Wed, 25 Dec 2024 06:23:49 +0100) 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:327080 Archived-At: > From: Gerd Möllmann > Cc: Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, > eller.helmut@gmail.com, acorallo@gnu.org > Date: Wed, 25 Dec 2024 06:23:49 +0100 > > > If they don't have separate stacks, and we interrupt MPS, the signal > > handler cannot look at any MPS-modifiable memory (including roots, which > > may be in an inconsistent state mid-GC), ever. This includes the > > specpdl. We can't write to MPS-known memory, ever. This includes any > > area we might want to copy the backtrace or specpdl to. > > And I don't think that's right :-). It's completely right that in the > SIGPROF handler everything can be inconsistent. That's true both for MPS > and Emacs. For example, the bindings stack (specpdl) may be inconsistent > when SIGPROF arrives. Theoretically, maybe. But in practice, you'd need to identify the code which manipulates specpdl that could have specpdl in inconsistent state if interrupted at some opportune point. Can you identify such places in the code? > Literally everything we do in the SIGPROF runs the > risk of encountering inconsistencies. Only if we interrupt code which leaves the global state inconsistent, and if what the SIGPROF handler does involves accessing those potentially-inconsistent data. > 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. With the old GC, we have special code to deal with this: /* Signal handler for sampling profiler. */ static void add_sample (struct profiler_log *plog, EMACS_INT count) { if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */ /* Special case the time-count inside GC because the hash-table code is not prepared to be used while the GC is running. More specifically it uses ASIZE at many places where it does not expect the ARRAY_MARK_FLAG to be set. We could try and harden the hash-table code, but it doesn't seem worth the effort. */ plog->gc_count = saturated_add (plog->gc_count, count); So all we need is for backtrace_top_function to be safe when SIGPROF arrives while we are in GC. Are you saying backtrace_top_function is unsafe in that case? > With MPS, from my POV, the situation is pretty similar. Try to get away > with it by not triggering MPS while in a state that we must assume is > inconsistent. The difference with MPS is that the old GC is synchronous with the Lisp machine, so it couldn't possibly start while we are modifying specpdl. That is no longer true with MPS, AFAIU, because MPS could start GC asynchronously. > >> The SIGPROF handler does two things: (1) get the current backtrace, > >> which does not trip on memory barriers, and > > > > Even if the specpdl were an ambiguous root, we'd be making very > > permanent and far-reaching assumptions about how MPS handles such roots > > if we assumed that we could even look at such roots during GC. This > > goes doubly for assuming that we can extract references to > > ambiguously-rooted objects and put them into other areas of MPS-visible > > memory. Even if this worked perfectly with current MPS on all > > platforms, it would still be unreasonable for us to rely on such > > implementation details. > > > > We can't do (1). > > I disagree, abviously :-) > > For me, it's not about a theoretical or even practical solution that > somehow ensures a consistent state in MPS, or some future changes in MPS > or something. It's about getting away with what we do in the profiler > _now_, as we do with the old GC. which is already seeing potentially > inconsistent state in Emacs' memory. See above: there's a difference. So I would really like to hear why you think accessing specpdl from a SIGPROF handler in an igc build is safe. > I think the _now_ is also important. From my POV, we could discuss > better solutions later. If you are right in your conclusions, certainly.