From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Pip Cet <pipcet@protonmail.com>
Cc: "Óscar Fuentes" <ofv@wanadoo.es>,
emacs-devel@gnu.org, "Helmut Eller" <eller.helmut@gmail.com>,
"Andrea Corallo" <acorallo@gnu.org>
Subject: Re: Make Signal handling patch platform-dependent?
Date: Mon, 23 Dec 2024 15:54:36 +0100 [thread overview]
Message-ID: <m2ttaufo0j.fsf@gmail.com> (raw)
In-Reply-To: <87v7vacvbe.fsf@protonmail.com> (Pip Cet's message of "Mon, 23 Dec 2024 14:45:55 +0000")
Pip Cet <pipcet@protonmail.com> writes:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Pip Cet <pipcet@protonmail.com> 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!
next prev parent reply other threads:[~2024-12-23 14:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-22 15:40 Some experience with the igc branch Óscar Fuentes
2024-12-22 17:18 ` Gerd Möllmann
2024-12-22 17:29 ` Gerd Möllmann
2024-12-22 17:41 ` Pip Cet via Emacs development discussions.
2024-12-22 17:56 ` Gerd Möllmann
2024-12-22 19:11 ` Óscar Fuentes
2024-12-23 0:05 ` Pip Cet via Emacs development discussions.
2024-12-23 1:00 ` Óscar Fuentes
2024-12-23 3:42 ` Gerd Möllmann
2024-12-23 6:27 ` Jean Louis
2024-12-22 20:29 ` Helmut Eller
2024-12-22 20:50 ` Gerd Möllmann
2024-12-22 22:26 ` Pip Cet via Emacs development discussions.
2024-12-23 3:23 ` Gerd Möllmann
[not found] ` <m234ieddeu.fsf_-_@gmail.com>
[not found] ` <87ttaueqp9.fsf@protonmail.com>
[not found] ` <m2frme921u.fsf@gmail.com>
[not found] ` <87ldw6ejkv.fsf@protonmail.com>
[not found] ` <m2bjx2h8dh.fsf@gmail.com>
2024-12-23 14:45 ` Make Signal handling patch platform-dependent? Pip Cet via Emacs development discussions.
2024-12-23 14:54 ` Gerd Möllmann [this message]
2024-12-23 15:11 ` Eli Zaretskii
2024-12-23 13:35 ` Some experience with the igc branch Eli Zaretskii
2024-12-23 14:03 ` Discussion with MPS people Gerd Möllmann
2024-12-23 14:04 ` Gerd Möllmann
2024-12-23 15:07 ` Some experience with the igc branch Pip Cet via Emacs development discussions.
2024-12-23 15:26 ` Gerd Möllmann
2024-12-23 16:03 ` Pip Cet via Emacs development discussions.
2024-12-23 16:44 ` Eli Zaretskii
2024-12-23 17:16 ` Pip Cet via Emacs development discussions.
2024-12-23 18:35 ` Eli Zaretskii
2024-12-23 18:48 ` Gerd Möllmann
2024-12-23 19:25 ` Eli Zaretskii
2024-12-23 20:30 ` Benjamin Riefenstahl
2024-12-23 17:44 ` Gerd Möllmann
2024-12-23 19:00 ` Eli Zaretskii
2024-12-23 19:37 ` Eli Zaretskii
2024-12-23 20:49 ` Gerd Möllmann
2024-12-23 21:43 ` Helmut Eller
[not found] ` <87r05yax5a.fsf@protonmail.com>
2024-12-23 21:58 ` Helmut Eller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2ttaufo0j.fsf@gmail.com \
--to=gerd.moellmann@gmail.com \
--cc=acorallo@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
--cc=pipcet@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).