unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



  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).