Re: MPS: profiler

[Eli Zaretskii]

> 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?

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?

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?