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: Make Signal handling patch platform-dependent? Date: Mon, 23 Dec 2024 14:45:55 +0000 Message-ID: <87v7vacvbe.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> <87ttaueqp9.fsf@protonmail.com> <87ldw6ejkv.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="19089"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?=C3=93scar_Fuentes?= , emacs-devel@gnu.org, Helmut Eller , Andrea Corallo To: =?utf-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 23 16:08:22 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 1tPk2e-0004lm-Ql for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Dec 2024 16:08:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPk1u-00052m-O7; Mon, 23 Dec 2024 10:07:34 -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 1tPjh7-0000tX-Oi for emacs-devel@gnu.org; Mon, 23 Dec 2024 09:46:05 -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 1tPjh4-0001Ov-SW; Mon, 23 Dec 2024 09:46:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734965160; x=1735224360; bh=ISj+ER3pK3I7uhweo+xkvkQyZBoK0jipcvQNU1XERCc=; 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=GWdPS2IkJY+dxhsAkyX6Z+h9UfdHFYwbldC/e4lhLoy6ODzi4KjBT65J/iXkMVchR wBxR2uQamaqIN6u0ynA/QPoy4wM8v1X49GD+umYU9YjmP8jk2xLRlrGGP2sUNhkY3L MmctZCKxIrW+Fm5l81ljchAHFdYvmgtFO23kb+EZ8D7TLToq5fc168wKvCuAGvvF0B rETJAyiQxSpidpKoboK5HHXx2Ra+PdDgTn0DUTZhmhrpQX/l7cSyrQ1soD0PCLRDXv oYqxc1YpGmIOaDte3IyRwV4+MUBkJ35/Brs1Z8/y8S8UpPhh7+UJNPNXZYDKvi/tit rjyPNG1CY1FhQ== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 149b06da0c010a0428d7f6aa476d5c5ffa8cd3a5 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_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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: Mon, 23 Dec 2024 10:07:31 -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:326911 Archived-At: Gerd M=C3=B6llmann writes: > Pip Cet writes: > >> And, who knows, using a separate thread might help (debugging, not >> performance). > > Yeah, more long-term goals, I'd guess. I'm glad we're moving forward, > ATM :-). If we come up with a solution to the signal issue which works but requires the creation of extra threads, would that prevent the merge? >> The rest of this email is about a half-baked idea to perform dry-run >> background GCs to facilitate debugging. It's tantalizingly close to >> offering performance benefits, but doesn't quite get there, and it >> doesn't have to: it'd help us detect leaked references to objects, and >> that's all it needs to do. >> >> I'm still thinking about double-mapping MPS segments so one thread can >> scan them using a "privileged" mapping while the barrier is in place for >> the ordinary mapping and prevents access to that segment. > > Quick question upfront; I'll have to think longer about the rest, and > maybe try to find existing examples: the double-mapping. How would that > be done? I know about page-table manipulation, but I don't think it's > easily doable, at least not on macOS. What would you use for > double-mapping? My understanding is the two options are SysV shm* (clunky) or mmapping a file handle corresponding to an already-deleted file, twice (some risk the OS will synchronize the file to disk, maybe even page it out; also might count towards the disk quota). I prefer the latter because I wouldn't actually delete the file, which would give us a snapshot of the MPS heap in the event of a crash. If that isn't enough, we could explicitly snapshot the file once in a while, before moving objects, giving us the ability to detect where an object moved to. (If THAT isn't enough, we'd have two additional options: either hack MPS not to reuse virtual addresses unless it really has to, or store the file on a fully journaled file system allowing us to time-travel through the MPS heap.) Also, I've never used shm*. If there's a third option, it'd be great to learn about it. Needless to say, double-mapping doubles the VM size, which is limited on 32-bit systems. I don't think virtually-indexed caches are a thing anymore (if the cache doesn't recognize two VAs correspond to the same PA, well, great fun ensues). IIUC, some aarch64 systems, but not those usually running macOS, have weak cache coherency, and as double-mapping is a valid but rare thing to do, who knows what would happen. Pip