[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPS: profiler
From: |
Gerd Möllmann |
Subject: |
Re: MPS: profiler |
Date: |
Fri, 21 Jun 2024 09:32:00 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- MPS: profiler, Ihor Radchenko, 2024/06/20
- Re: MPS: profiler, Eli Zaretskii, 2024/06/20
- Re: MPS: profiler, Ihor Radchenko, 2024/06/20
- Re: MPS: profiler, Gerd Möllmann, 2024/06/20
- Re: MPS: profiler, Ihor Radchenko, 2024/06/20
- Re: MPS: profiler, Gerd Möllmann, 2024/06/21
- Re: MPS: profiler, Eli Zaretskii, 2024/06/21
- Re: MPS: profiler, Gerd Möllmann, 2024/06/21
- Re: MPS: profiler, Eli Zaretskii, 2024/06/21
- Re: MPS: profiler,
Gerd Möllmann <=
- Re: MPS: profiler, Helmut Eller, 2024/06/21
- Re: MPS: profiler, Ihor Radchenko, 2024/06/21
- Re: MPS: profiler, Helmut Eller, 2024/06/21
- Re: MPS: profiler, Gerd Möllmann, 2024/06/21
- Re: MPS: profiler, Helmut Eller, 2024/06/21
- Re: MPS: profiler, Gerd Möllmann, 2024/06/21
- Re: MPS: profiler, Eli Zaretskii, 2024/06/21
- Re: MPS: profiler, Gerd Möllmann, 2024/06/21
- Re: MPS: profiler, Helmut Eller, 2024/06/21
- Re: MPS: profiler, Ihor Radchenko, 2024/06/21