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: Tue, 24 Dec 2024 21:18:32 +0000 Message-ID: <87y104aih6.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> 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="31736"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: =?utf-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 04:21:43 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 1tQHxu-00085Q-Ea for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 04:21:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQHx2-0008TX-BY; Tue, 24 Dec 2024 22:20:48 -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 1tQCIe-00057A-ET for emacs-devel@gnu.org; Tue, 24 Dec 2024 16:18:45 -0500 Original-Received: from mail-10628.protonmail.ch ([79.135.106.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQCIc-0002SF-LG; Tue, 24 Dec 2024 16:18:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735075118; x=1735334318; bh=D22fIWA/h3YYUI2VlFwkiRqRXxNP8tD5F2LFKacmuVQ=; 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=EsctLXlm3h27FO0cfs6IppvIyHz/E81K6VmIUWtWtpuQx7F8lpl0+wwoEP9fqArwL VuWIs1DXJTD/74Fo/2Xm4APdWXoYCUuQdBh8/o0FOzuVIG6ywOA4rlziAp8M63VcAS hF9AsUPPj9LpdYeFz4MERyMW8twj/UxEwH+01A4PkxKgpMzCLBjjYX+co2oAolCbvd JNBxy9qnEI6hjPXbv5vcgrKecZ18TMUVpfDtQPGX40fiUOJrUuRR7G1oGKQf3x74vm zVVFrFyXgm7gASvB6ZLM4kZzY66vpJ/DT0j6SYLKf3rznp4y+i1qqeULz1L/SDMR/C pEDlZ83+OIBWw== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 176dbbcdbe7ed5fe130a750fe780fc92cf53e889 Received-SPF: pass client-ip=79.135.106.28; envelope-from=pipcet@protonmail.com; helo=mail-10628.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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 24 Dec 2024 22:20:46 -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:327046 Archived-At: Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: > We're coming from the problem that MPS uses signals for memory barriers. > On platforms !=3D macOS. And I am proposing a solution for that. I don't think that's the problem. The problem is that signals can interrupt MPS, on all platforms. We can't have MPS-signal-MPS stacks, ever. The best way to ensure that is to keep signals on one stack, and MPS on another stack. MacOS already does that for their SIGSEGV equivalent, but we need to do it for all entry points into MPS. 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. > 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). >> Doing this from another thread raises the problem I describe above: we >> need the Lisp thread(s) stopped, because you cannot examine the data >> of the Lisp machine while the machine is running. And if we stop the >> Lisp threads, why do we need the other thread at all? Because MPS can continue and reach an MPS-consistent state only if it has its own stack. In practice, this means an extra thread. Or we re-raise signals (scratch/igc right now; this will delay signals unpredictably), or we block them for the allocation fast path (significant slowdown on some systems) *and* in the SIGSEGV handler (which we'd need to "steal" from MPS, calling it from our real signal handler by extracting sa_sigaction and calling that pointer. Recipe for disaster). I'm still convinced the extra thread is the least painful option, followed by what we have now. Pip