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 14:19:23 +0200 Message-ID: <86ldw40xbo.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> 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="2739"; 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 13:19:47 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 1tQQMc-0000Z8-RL for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 13:19:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQQMM-00057z-Ed; Wed, 25 Dec 2024 07:19:30 -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 1tQQMJ-00057k-Q0 for emacs-devel@gnu.org; Wed, 25 Dec 2024 07:19:27 -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 1tQQMI-0007cr-TH; Wed, 25 Dec 2024 07:19:26 -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=DuBbR1yPS6xxWrDf9ZZUTnuK4NQed495kTXdRQ/xgII=; b=p4XCEQUuNNivrxRMVlv8 7pAgxxPSBtX435DjdeFNKcSz+LCAR6niYeWr1wuYBD+9ndIZzK/1UJXF3VlwP1AGyl6vBeyO72RHN oHm5h0KkTo2N+O2Ld9alo44QCiIGet/UcYNouLVZlbcNJfpapBwCOCatcYFD5fuMZO8hw2NxleOml PAIQgNN7kTlMyFRPPV4Xiehf/45l5kYEFgYJ+CLX3HeEXephvJ9WxO0q876zN/9bl3Yj1y6a0yRin vEh8UPe5Y5L5OZgM4aakRNhNu9sBQ0Yzakz8G5i+jBjyNpdktQ7MVh71laK+Rexawgm7T7W4UisAT naotpYDI4DvmDw==; In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Wed, 25 Dec 2024 05:56:26 +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:327078 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 05:56:26 +0100 > > Eli Zaretskii writes: > > >> The SIGPROF handler does two things: (1) get the current backtrace, > >> which does not trip on memory barriers, and (2) build a summary, i.e. > >> count same backtraces using a hash table. (2) trips on memory barriers. > > > > Can you elaborate on (2) and why it trips? I guess I'm missing > > something because I don't understand which code in record_backtrace > > does trip on memory barriers and why. > > Ok, (2) begins as shown below. > > static void > record_backtrace (struct profiler_log *plog, EMACS_INT count) > { > log_t *log = plog->log; > get_backtrace (log->trace, log->depth); > --- (2) begins after this line ------------------------------- > EMACS_UINT hash = trace_hash (log->trace, log->depth); > > The SIGPROF can have interrupted Emacs at any point, both the MPS thread > and all others. MPS may have been doing arbitrary stuff when > interrupted, and Emacs threads too. Memory barriers may be on > unpredictable segments of memory, as they usually are, as part of MPS' > GC implementation. Do you agree with this picture? > > Elsewhere I tried to explain why I think this works up to the line > marked (2) above. Now enter trace_hash. Current implementation: > > static EMACS_UINT > trace_hash (Lisp_Object *trace, int depth) > { > EMACS_UINT hash = 0; > for (int i = 0; i < depth; i++) > { > Lisp_Object f = trace[i]; > EMACS_UINT hash1; > #ifdef HAVE_MPS > hash1 = (CLOSUREP (f) ? igc_hash (AREF (f, CLOSURE_CODE)) : igc_hash (f)); > ^^^^^^^^ ^^^^^^^^ ^^^^ > > The constructs I marked with ^^^ all access the memory of F. F is a > vectorlike, it's memory is managed by MPS in an MPS pool that uses > memory barriers, so the memory of F can currently be behind a barrier. > It doesn't have to, but it can. > > When we access F's memory and it is behind a barrier, the result is a > nested SIgSEGV while handling SIGPROF. Two followup questions: . how is accessing F different from accessing the specpdl stack? . how does this work with the current GC, where F could have been collected and its memory freed? The first question is more important, from where I stand. Looking forward beyond the point where we land igc on master, I wonder how will be able to tell, for a random non-trivial change on the C level, whether what it does can cause trouble with MPS? That is, how can a mere mortal determine whether a given data structure in igc Emacs can or cannot be safely touched when MPS happens to do its thing, whether synchronously or asynchronously? We must have some reasonably practical way of telling this, or else we will be breaking Emacs high and low. > 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.)