From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org,
eller.helmut@gmail.com, acorallo@gnu.org
Subject: Re: Some experience with the igc branch
Date: Wed, 25 Dec 2024 13:50:37 +0100 [thread overview]
Message-ID: <m2a5ckapuq.fsf@gmail.com> (raw)
In-Reply-To: <86ldw40xbo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 25 Dec 2024 14:19:23 +0200")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org,
>> eller.helmut@gmail.com, acorallo@gnu.org
>> Date: Wed, 25 Dec 2024 05:56:26 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> The SIGPROF handler does two things: (1) get the current backtrace,
>> >> which does not trip on memory barriers, and (2) build a summary, i.e.
>> >> count same backtraces using a hash table. (2) trips on memory barriers.
>> >
>> > Can you elaborate on (2) and why it trips? I guess I'm missing
>> > something because I don't understand which code in record_backtrace
>> > does trip on memory barriers and why.
>>
>> Ok, (2) begins as shown below.
>>
>> static void
>> record_backtrace (struct profiler_log *plog, EMACS_INT count)
>> {
>> log_t *log = plog->log;
>> get_backtrace (log->trace, log->depth);
>> --- (2) begins after this line -------------------------------
>> EMACS_UINT hash = trace_hash (log->trace, log->depth);
>>
>> The SIGPROF can have interrupted Emacs at any point, both the MPS thread
>> and all others. MPS may have been doing arbitrary stuff when
>> interrupted, and Emacs threads too. Memory barriers may be on
>> unpredictable segments of memory, as they usually are, as part of MPS'
>> GC implementation. Do you agree with this picture?
>>
>> Elsewhere I tried to explain why I think this works up to the line
>> marked (2) above. Now enter trace_hash. Current implementation:
>>
>> static EMACS_UINT
>> trace_hash (Lisp_Object *trace, int depth)
>> {
>> EMACS_UINT hash = 0;
>> for (int i = 0; i < depth; i++)
>> {
>> Lisp_Object f = trace[i];
>> EMACS_UINT hash1;
>> #ifdef HAVE_MPS
>> hash1 = (CLOSUREP (f) ? igc_hash (AREF (f, CLOSURE_CODE)) : igc_hash (f));
>> ^^^^^^^^ ^^^^^^^^ ^^^^
>>
>> The constructs I marked with ^^^ all access the memory of F. F is a
>> vectorlike, it's memory is managed by MPS in an MPS pool that uses
>> memory barriers, so the memory of F can currently be behind a barrier.
>> It doesn't have to, but it can.
>>
>> When we access F's memory and it is behind a barrier, the result is a
>> nested SIgSEGV while handling SIGPROF.
>
> Two followup questions:
>
> . how is accessing F different from accessing the specpdl stack?
F's memory is allocated from an MPS pool via alloc_impl in igc.c. Most
objects are allocated from a pool that uses barriers (I think except
PVEC_THREAD). The specpdl stacks are mallocs (see
grow_specpdl_allocation), and uses as a roots. There are currently no
barriers on roots.
> . how does this work with the current GC, where F could have been
> collected and its memory freed?
I think when we find F in a specpdl stack, GC should have seen it and
marked it too in mark_specpdl. So it wouldn't be freed.
(Same for igc, where the stacks are roots, and should have seen F in
that way in scan_specdl.)
> The first question is more important, from where I stand. Looking
> forward beyond the point where we land igc on master, I wonder how
> will be able to tell, for a random non-trivial change on the C level,
> whether what it does can cause trouble with MPS? That is, how can a
> mere mortal determine whether a given data structure in igc Emacs can
> or cannot be safely touched when MPS happens to do its thing, whether
> synchronously or asynchronously? We must have some reasonably
> practical way of telling this, or else we will be breaking Emacs high
> and low.
>
>> More code accessing memory that is potentially behind a barrier follows
>> in record_backtrace.
>
> Which code is that? (It's a serious question: I tried to identify
> that code, but couldn't. I'm probably missing something.)
The example I saw, with ^^^^ marking the call sites:
static void
record_backtrace (struct profiler_log *plog, EMACS_INT count)
{
log_t *log = plog->log;
get_backtrace (log->trace, log->depth);
EMACS_UINT hash = trace_hash (log->trace, log->depth);
int hidx = log_hash_index (log, hash);
int idx = log->index[hidx];
while (idx >= 0)
{
if (log->hash[idx] == hash
&& trace_equal (log->trace, get_key_vector (log, idx), log->depth))
^^^^^^^^^^^
static bool
trace_equal (Lisp_Object *bt1, Lisp_Object *bt2, int depth)
{
for (int i = 0; i < depth; i++)
if (!BASE_EQ (bt1[i], bt2[i]) && NILP (Ffunction_equal (bt1[i], bt2[i])))
^^^^^^^^^^^^^^^
DEFUN ("function-equal", Ffunction_equal, Sfunction_equal, 2, 2, 0,
doc: /* Return non-nil if F1 and F2 come from the same source.
Used to determine if different closures are just different instances of
the same lambda expression, or are really unrelated function. */)
(Lisp_Object f1, Lisp_Object f2)
{
bool res;
if (EQ (f1, f2))
res = true;
else if (CLOSUREP (f1) && CLOSUREP (f2))
^^^^^^^^ ^^^^^^^^
res = EQ (AREF (f1, CLOSURE_CODE), AREF (f2, CLOSURE_CODE));
^^^^ ^^^^
Didn't look further than that, though.
next prev parent reply other threads:[~2024-12-25 12:50 UTC|newest]
Thread overview: 107+ 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-24 22:34 ` Pip Cet via Emacs development discussions.
2024-12-25 4:25 ` Freezing frame with igc Gerd Möllmann
2024-12-25 11:19 ` Pip Cet via Emacs development discussions.
2024-12-25 11:55 ` Óscar Fuentes
2024-12-23 3:42 ` Some experience with the igc branch 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
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 23:39 ` Pip Cet via Emacs development discussions.
2024-12-24 12:14 ` Eli Zaretskii
2024-12-24 13:18 ` Pip Cet via Emacs development discussions.
2024-12-24 13:42 ` Benjamin Riefenstahl
2024-12-24 3:37 ` Eli Zaretskii
2024-12-24 8:48 ` Benjamin Riefenstahl
2024-12-24 13:52 ` Eli Zaretskii
2024-12-24 13:54 ` 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
2024-12-23 21:49 ` Pip Cet via Emacs development discussions.
2024-12-23 21:58 ` Helmut Eller
2024-12-23 23:20 ` Pip Cet via Emacs development discussions.
2024-12-24 5:38 ` Helmut Eller
2024-12-24 6:27 ` Gerd Möllmann
2024-12-24 10:09 ` Pip Cet via Emacs development discussions.
2024-12-24 4:05 ` Gerd Möllmann
2024-12-24 8:50 ` Gerd Möllmann
2024-12-24 6:03 ` SIGPROF + SIGCHLD and igc Gerd Möllmann
2024-12-24 8:23 ` Helmut Eller
2024-12-24 8:39 ` Gerd Möllmann
2024-12-25 9:22 ` Helmut Eller
2024-12-25 9:43 ` Gerd Möllmann
2024-12-24 13:05 ` Eli Zaretskii
2024-12-25 10:46 ` Helmut Eller
2024-12-25 12:45 ` Eli Zaretskii
2024-12-24 12:54 ` Eli Zaretskii
2024-12-24 12:59 ` Gerd Möllmann
2024-12-23 23:37 ` Some experience with the igc branch Pip Cet via Emacs development discussions.
2024-12-24 4:03 ` Gerd Möllmann
2024-12-24 10:25 ` Pip Cet via Emacs development discussions.
2024-12-24 10:50 ` Gerd Möllmann
2024-12-24 13:15 ` Eli Zaretskii
2024-12-24 12:26 ` Eli Zaretskii
2024-12-24 12:56 ` Gerd Möllmann
2024-12-24 13:19 ` Pip Cet via Emacs development discussions.
2024-12-24 13:38 ` Gerd Möllmann
2024-12-24 13:46 ` Eli Zaretskii
2024-12-24 14:12 ` Gerd Möllmann
2024-12-24 14:40 ` Eli Zaretskii
2024-12-25 4:56 ` Gerd Möllmann
2024-12-25 12:19 ` Eli Zaretskii
2024-12-25 12:50 ` Gerd Möllmann [this message]
2024-12-25 13:00 ` Eli Zaretskii
2024-12-25 13:08 ` Gerd Möllmann
2024-12-25 13:26 ` Eli Zaretskii
2024-12-25 14:07 ` Gerd Möllmann
2024-12-25 14:43 ` Helmut Eller
2024-12-25 14:59 ` Eli Zaretskii
2024-12-25 20:44 ` Helmut Eller
2024-12-25 15:02 ` Gerd Möllmann
2024-12-25 13:09 ` Eli Zaretskii
2024-12-25 13:46 ` Gerd Möllmann
2024-12-25 14:37 ` Eli Zaretskii
2024-12-25 14:57 ` Gerd Möllmann
2024-12-25 15:28 ` Eli Zaretskii
2024-12-25 15:49 ` Gerd Möllmann
2024-12-25 17:26 ` Eli Zaretskii
2024-12-25 17:40 ` Pip Cet via Emacs development discussions.
2024-12-25 17:51 ` Eli Zaretskii
2024-12-24 21:18 ` Pip Cet via Emacs development discussions.
2024-12-25 5:23 ` Gerd Möllmann
2024-12-25 10:48 ` Pip Cet via Emacs development discussions.
2024-12-25 13:40 ` Stefan Kangas
2024-12-25 17:03 ` Pip Cet via Emacs development discussions.
2024-12-25 11:48 ` Helmut Eller
2024-12-25 11:58 ` Gerd Möllmann
2024-12-25 12:52 ` Eli Zaretskii
2024-12-25 12:31 ` Eli Zaretskii
2024-12-25 12:54 ` Gerd Möllmann
2024-12-24 12:11 ` Eli Zaretskii
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=m2a5ckapuq.fsf@gmail.com \
--to=gerd.moellmann@gmail.com \
--cc=acorallo@gnu.org \
--cc=eliz@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).