From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Wed, 25 Dec 2024 15:00:01 +0200 Message-ID: <86a5cj2a0e.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> <86seqe4j4f.fsf@gnu.org> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21504"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 25 14:00:57 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tQR0T-0005Om-2v for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 14:00:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQQzm-0001E3-3F; Wed, 25 Dec 2024 08:00:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQQzk-0001DS-Mr for emacs-devel@gnu.org; Wed, 25 Dec 2024 08:00:12 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tQQzj-0007BP-Gr; Wed, 25 Dec 2024 08:00:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=6yrLj8z5yGTrmpgGVR3o0PczXHquusBCVZpC6P0YOyg=; b=WQFOwi2ieAVvg8daxkKU m0w6LJt6gg4bkRguKPJDTcP6Po+K7bxylFz7O7Mjw92VGIw7IHGGKKaIVq8ssx6ZzWX2Gl14yOR+N Qv9A3/kLlpC9n2VLQkr7YOFkF2Efw99DF4c7btI7CAB3VnQZ+sdZ8ss7oT5RFArngrohZOKNeZIQj TLDegPVzM+FohDZEKyf+cmFPJTSgV1lIoZAmol1bNUa2CeSPJBsveynqtVGg0cdlm2mQFpvgHmsxH 2GTzYQkF/bg5Vtxh4tELgPfZPzlO6NkZQRQb0Gs2t9O85uj2dhmatRJqCLSKBikopIZVfIIXmdtIl BfMT2njNEODvSA==; In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Wed, 25 Dec 2024 13:50:37 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327086 Archived-At: > From: Gerd Möllmann > 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 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?