Re: MPS: profiler

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Ihor Radchenko <yantar92@posteo.net>,  emacs-devel@gnu.org,
>>   eller.helmut@gmail.com
>> Date: Fri, 21 Jun 2024 08:54:34 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Also, can 'static struct profiler_log cpu', which is being worked on
>> > by record_backtrace, be affected by MPS in any way?
>> 
>> I'd guess that just "touching" Lisp objects in the SIGPROF handler can
>> be problematic because these objects themselves can be behind a barrier,
>> either the same that MPS is currently working on when it got interrupted
>> or another one.
>
> Which Lisp objects do we touch in record_backtrace?  All I see is that
> we access spec_pdl and its data.  Is that supposed to be dangerous
> while MPS does its thing?

I don't know. In the backtrace I commented on in a reply to Ihor, we had
this:

  #0  0x00005555558b53d6 in PSEUDOVECTORP (a=0x7fffe6dde715, code=32) at /home/yantar92/Git/emacs/src/lisp.h:1104
  #1  0x00005555558b567f in CLOSUREP (a=0x7fffe6dde715) at /home/yantar92/Git/emacs/src/lisp.h:3368
  #2  0x00005555558b5b80 in trace_hash (trace=0x555556329400, depth=16) at profiler.c:189


>
> Also note that add_sample (called by the SIGPROF handler) does this:
>
>   if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */
>     /* Special case the time-count inside GC because the hash-table
>        code is not prepared to be used while the GC is running.
>        More specifically it uses ASIZE at many places where it does
>        not expect the ARRAY_MARK_FLAG to be set.  We could try and
>        harden the hash-table code, but it doesn't seem worth the
>        effort.  */
>     plog->gc_count = saturated_add (plog->gc_count, count);
>   else
>     record_backtrace (plog, count);
>
> IOW, it avoids recording the backtrace if called during GC.  Perhaps
> we should do the same with igc?  Or doe we already set up
> backtrace_top_function to return QAutomatic_GC in that case?

I don't think we do. I'm not even sure we could do that reliably since
MPS is running concurrently.

> And finally, I see in make_log that we already do something about the
> log variables that is specific to MPS.  Is that not enough to prevent
> this kind of issues?

No, that's just making sure we trace what's in the malloc'd memory.