Re: Some experience with the igc branch

[Gerd Möllmann]

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 13:50:37 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> 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.
>
> But CLOSUREP is just
>
>   INLINE bool
>   CLOSUREP (Lisp_Object a)
>   {
>     return PSEUDOVECTORP (a, PVEC_CLOSURE);
>   }

PSEUDOVECTORP reads the vectorlike_header header from A's memory.

> And AREF is even simpler:
>
>   INLINE Lisp_Object
>   AREF (Lisp_Object array, ptrdiff_t idx)
>   {
>     eassert (0 <= idx && idx < gc_asize (array));
>     return XVECTOR (array)->contents[idx];
>   }

And AREF accesses ARRAY's memory via ->contents.

> So why are those unsafe?  Because they access Lisp objects, or for
> some other reason?

What do you mean with unsafe? We are accessing an object's memory. That
memory may potentially be protected by a barrier. I thought we agreed on
that.