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: last_marked array is now ifdef'ed away Date: Sun, 15 Sep 2024 17:21:21 +0300 Message-ID: <861q1ldmla.fsf@gnu.org> References: <86zfokyp64.fsf@gnu.org> <86ed5pkz53.fsf@gnu.org> <851C7C12-44A1-4661-9EA7-16B0B7209D11@gmail.com> <86a5gbk295.fsf@gnu.org> <8634m2f8ii.fsf@gnu.org> <86o74pea7k.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="22414"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 15 16:22:26 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 1spq8v-0005gj-6Q for ged-emacs-devel@m.gmane-mx.org; Sun, 15 Sep 2024 16:22:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1spq82-0002aE-9J; Sun, 15 Sep 2024 10:21:30 -0400 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 1spq7z-0002a1-JB for emacs-devel@gnu.org; Sun, 15 Sep 2024 10:21:28 -0400 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 1spq7x-00075d-HI; Sun, 15 Sep 2024 10:21:26 -0400 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=W1gDf49TJ5Ow9IPRidOQy5LYbtdvqmlJ9fVfSfGRtJk=; b=qHjaqMFh4er95dNnzma6 lVwxfMcy5dbrmekrNiuiMOAQwntFbnvnwbo6DBp60kFeKzmM2trOAQ/3NIMyxzEE6zZrVS4NRshMF kc+gUkAKTiDrat/DOZ8Z37qh9Kg8Xq3G5DegpwLnyYzORyveo3FJp+idKz/O+jSlvkDg2gjqUM3ss /aulMMivFTBO+wxp3LBUjmKXoK4/4DyQJz8Qu7XpU6zH7KE2MOLJDLeX4j5jhpQVoWQ/NzRPZoiu2 F1pcz7917VfG7S47Uyu/JGzmLSubYTcJGNbGi9B5dgcgWsu0CFVAa5AxTvNrKCOHFi18rhhnvflz1 GWSU1qk4pmHGqQ==; In-Reply-To: (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Sun, 15 Sep 2024 15:58:03 +0200) 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:323636 Archived-At: > From: Mattias Engdegård > Date: Sun, 15 Sep 2024 15:58:03 +0200 > Cc: emacs-devel@gnu.org > > 15 sep. 2024 kl. 07.51 skrev Eli Zaretskii : > > > I'd need to see actual evidence for a shorter array, based on actual > > GC run of some data structure. > > And I'd need to see actual evidence for a longer array, based on actual debugging cases. There's no need for any evidence to keep the code which we always had. Evidence is needed when changes are suggested that modify stuff in significant ways. > But perhaps there is a way for both of us to be just slightly disappointed: what about gating the check with a flag? That way, the trace buffer is always compiled-in. It needs to be enabled by the user but that is straightforward and can be done on the command line, in Lisp, or in a debugger. That won't help because GC crashes are seldom if ever reproducible. So if the trace is off, the information is gone and cannot be recovered in practice. I'm not just being stubborn, there really is no way around this. Leaving this disabled, no matter in what way, basically means we delete the feature. Because it can never be enabled in time for the problem to strike.