emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some experience with the igc branch


From: Eli Zaretskii
Subject: Re: Some experience with the igc branch
Date: Wed, 25 Dec 2024 15:00:01 +0200

> 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);
  }

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];
  }

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]