From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Wed, 25 Dec 2024 06:23:49 +0100 Message-ID: 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: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31065"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 06:24:48 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 1tQJt1-0007vL-KS for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 06:24:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQJsE-0003ta-3N; Wed, 25 Dec 2024 00:23:58 -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 1tQJsC-0003t8-Px for emacs-devel@gnu.org; Wed, 25 Dec 2024 00:23:56 -0500 Original-Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQJsB-0000XW-5p; Wed, 25 Dec 2024 00:23:56 -0500 Original-Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5d3d2a30afcso9595118a12.3; Tue, 24 Dec 2024 21:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735104232; x=1735709032; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1DDOBiN1BfxOSMV3FYIOsvKwaic1AJp4yK0FOISYN7Y=; b=fahU9PfbS3HjMrk4wWkOMkYrWMngUQDeq4TJp3e5N6De6rIukk+ZUmHMPcdn86RRsL PrtA08PRac+LTp2Jw4e+Hw3ZqKGhWsl7LQ5sQzzR2S2cfZ7MMJlPT4/bkPx9j+bmP6Fv jZor5yBdmW30z7X0rHh3L4Pgq9Dr6Hhcn1snEx1BqQLkWh3BzG2BS2rMkzbJCvdk/zhX zakyykwWUOROsLYnp+0t5bqpjLZ8T8XLOWrNGz+rC5JzMt3YVDnT/ebdEIRCKfZBSpLS vkXRpUtQtJiFpfMtn2+h4NpUMrlXID/bioAir4yUS9WoE28RhaeyPVCidusRFrUq3aPx UVtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735104232; x=1735709032; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1DDOBiN1BfxOSMV3FYIOsvKwaic1AJp4yK0FOISYN7Y=; b=nTi5+CCDT6h31zvvXAn9mwEZ343D/R+LIwoKS/+yteHOoomhzeDfTe/nFtBkTu+Mdd e6wfGYvcLOwMu6ks/1hcsKFjLpS9kayrjZf7asRkTNvYjCk6zCGinR31JIl2yQiY++i4 O2fEJvIzoOBJcJfAcW9OkYG4daN4k/1TRA3JIzGDBFy94ToED49ly8ZqYLzEzgnJmE24 H27S85gW+X8+m4B8HM7znNtiZzmFm81kikUYpF8xal1edSyq+42P2QLozu/T6alZj5oZ xKdVxOdaOdaTf3KeGbeHMPzpmahVp1E2m0fyL872WXUD9W0Nqb32ety1pWdWKoCOr5rv v4vw== X-Forwarded-Encrypted: i=1; AJvYcCW9GQLUpK9eeT+vybZ79zYSYpfu4x1L779a5rRw7VNj9OTf46BkWUFQt+ngyNjYKm2cF7z7H6gJ30ejjrU=@gnu.org, AJvYcCXIYm1m6mlmNlyefvyM8k/wx0lDevRuf3DefqJ/qWNQf42Ye4ACW0U2UP3yS+SAP/Ui1CAv7TIoCQ==@gnu.org X-Gm-Message-State: AOJu0YzDC9KR8I6wE2fySu8/8G3LFs/kTKznWqRRVPSA4UGzFb/BnhV1 1hf3k+b5kbBYHBesmDK4POCr+U1WLulpfNfDc11ptp+OZfDctWgXwJuzzA== X-Gm-Gg: ASbGnctrUHDZaqUEDBX89EhsXj2r9aB9h/rVzNuI8ECWZpW7nJH5GDAayqjpnlR0mty vlg4rwjVcL+N1IXhL1NFEjGxOTAleQd2UReYwZEGbbZu9/rRUQ6mZ9dJAtBa7BiXXh3GFyQ594Z y7EaE2CA/POGsozx0ge/hlwOqeWgbuRClJl5k6TXNTjm28wO4zikRkAEyNM52x8o6tIXwxiBFhF iYujRIWj7vqfUU6AkWtax4OuPOlnUr1NvsnQWRrel6xx7kJuiNPcH5nDmPQU+11+RfDrYEtxwlp ge+ZokQ+Bq47xILaokvFonc8TifYdKesf0CDoHD/Ve6E/x8oIvJyY7Br0d2cgjV5Sg== X-Google-Smtp-Source: AGHT+IFa+sv5sdyocT7KlxoydoUMNnLj/LASQkZpEpAmeWB3vUUElMX9u4/uBhLMxm9LTkqSuZOTuQ== X-Received: by 2002:a17:907:1c15:b0:aab:e07c:78b7 with SMTP id a640c23a62f3a-aac2b84a1d8mr1400800466b.23.1735104232274; Tue, 24 Dec 2024 21:23:52 -0800 (PST) Original-Received: from pro2 (p200300e0b73d6f00401d1c7c2fc22e2d.dip0.t-ipconnect.de. [2003:e0:b73d:6f00:401d:1c7c:2fc2:2e2d]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d80679eeb1sm6989877a12.48.2024.12.24.21.23.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Dec 2024 21:23:51 -0800 (PST) In-Reply-To: <87y104aih6.fsf@protonmail.com> (Pip Cet's message of "Tue, 24 Dec 2024 21:18:32 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::52d; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52d.google.com 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:327055 Archived-At: Pip Cet writes: > 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. 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. Literally everything we do in the SIGPROF runs the risk of encountering inconsistencies. 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 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 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. I think the _now_ is also important. From my POV, we could discuss better solutions later.