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: Make Signal handling patch platform-dependent? Date: Mon, 23 Dec 2024 15:54:36 +0100 Message-ID: References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> <87ttaueqp9.fsf@protonmail.com> <87ldw6ejkv.fsf@protonmail.com> <87v7vacvbe.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="6085"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , emacs-devel@gnu.org, Helmut Eller , Andrea Corallo To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 23 15:55:33 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 1tPjqG-0001Rz-G9 for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Dec 2024 15:55:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPjpV-0002GS-Ud; Mon, 23 Dec 2024 09:54:45 -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 1tPjpS-0002GG-G8 for emacs-devel@gnu.org; Mon, 23 Dec 2024 09:54:45 -0500 Original-Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tPjpQ-00023D-RY; Mon, 23 Dec 2024 09:54:42 -0500 Original-Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-aab6fa3e20eso731267266b.2; Mon, 23 Dec 2024 06:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734965678; x=1735570478; 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=dzfypQbuGjHh4R6pKEBp3avtHzt4qcIs4Gh60xrBBow=; b=HO1RMEVL5SvefWDeEDbSqqL7jEbywBWPTR9TdgdNj6n9xbyibQIQdLPy3x7CJEvBoy lJv5388j6JE8XJ4fIk7EygQ4/s/rpKdhori33hLveq+Hn9RsnymqDqwe632I2jfmsjEN A6isj74ZhUWKjFfHCEt926aHYnBGoyUwJjxihADgoy6nqEHkjKHjvLn8xdnzY9TsQ9P5 Jwkn2UljZJtfhqZJ+KLXN1uA2QDm0MmY0kMrmNDSFXmGMSjqGki8QIFYhqOd0U+Bf1gZ Btg5Ny7vgNAK0cskcMJh1NScH9DPVS8c5f98iH0t+6mY1p040sTJzMOVVe0uj2nRGi0z juPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734965678; x=1735570478; 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=dzfypQbuGjHh4R6pKEBp3avtHzt4qcIs4Gh60xrBBow=; b=fPqiO5AAnQkvR0QK4+mygLXSiJ9VgCJGIXGze1gb//PYzFgVyaAlvXvGhJKAopV5vT iCtk1HtCCOXmWFHBVCZYPxfR+XYJHt1z7ezUmvJncVrkW1ZtKBC3b+KkmWNSyH8+Q+DN 48jjS2Lk36Znb59ZiB8Nk6JZfB1YCcAa1vwCwf7Tw4FTDbCS7yArdpF4fpIiCd+q0BzJ bpPVVMws588Wl7yIK+ZUuZn9MR6U3FjH51vY3D78t8jey6BluOxvp5BXYCCHdmwJ0dFG zrDpzL1I+NPlU/hjl/2AyZImqQtOzobdwE6RCNUXTCILTRa43X0P3HVNJgk5UBedSG/F qK1A== X-Forwarded-Encrypted: i=1; AJvYcCUla6qMHqCTqR5HM+wz8E3nSk371KzdMyfdLD3C1LqDhKbIny5Raik4Jsh5CTtsoIOAC854Z+2eRA==@gnu.org, AJvYcCWmZ4lpvTxHU3ww3p87tf+Z1Hdtw7rYTcJgjTMvKiDi/LOgFKrx5xt06FDlGaQVedvHHuq42stCniomlq4=@gnu.org X-Gm-Message-State: AOJu0YyKFFP5NxAFBIvGn0JDiAWOW/SA4JoG4OtcsbulnV1CuilgeX4Y pLev47AR/T3T2tgjSXo3nc6A6WfEX5NKcdIPUvRLxDNc7T+R5TRioGLjdQ== X-Gm-Gg: ASbGncuSkaSyhlrJnXW/SQ3AvZvvksOhIIgM4eoxXUU7m+PL2IvxnGIznb5w/uHLedM Ub3vmUXW64Ik9322BlndJ3o2umAk8dGdb9ea+0U7kz/KNjvqyqqiZNQEIF6DVksSDKMSLgdlml4 T9RZFWsXSb59N4dvV+kjqwEEJGPED3MvbXapdCExjjuOXkf0tobSjeplzB9GS97w1Px32Y6gS+k nJblJXuKx/rUhQm8kvlnAOGTogdQsEgYVfREYFPSW1k2pfWQLaCEg8fAHVcWENaE0pVrSf2nVmA uqFo51fEaZSQkWFLjnz0INZsFevBfHX50Qq1H+ocYLOjMPUFPKkGzxGpc4yfczwQgQ== X-Google-Smtp-Source: AGHT+IEg7jheq0Phf396y5/DK7mu0NfkB4GVxr2UsGHKnJTIDoUIQcAjdoVw0cdj+qm9dKyE91hfDQ== X-Received: by 2002:a17:906:ef0b:b0:aa6:7d82:5414 with SMTP id a640c23a62f3a-aac334c3de4mr1310178666b.30.1734965678106; Mon, 23 Dec 2024 06:54:38 -0800 (PST) Original-Received: from pro2 (p200300e0b728c00045f88d4d4db0c1e7.dip0.t-ipconnect.de. [2003:e0:b728:c000:45f8:8d4d:4db0:c1e7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0eae5902sm523644166b.85.2024.12.23.06.54.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Dec 2024 06:54:37 -0800 (PST) In-Reply-To: <87v7vacvbe.fsf@protonmail.com> (Pip Cet's message of "Mon, 23 Dec 2024 14:45:55 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::633; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x633.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:326910 Archived-At: Pip Cet writes: > 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? I think that's for Eli to answer. >>> 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. I don't know of a third option. > > 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 Thanks so far!