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: MPS: struct window, prev_buffers + next_buffers Date: Sat, 22 Jun 2024 10:58:39 +0300 Message-ID: <861q4pjtn4.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17519"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, eller.helmut@gmail.com To: Gerd =?iso-8859-1?Q?M=F6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 22 09:59:35 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 1sKveo-0004OG-Ks for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Jun 2024 09:59:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKve0-0002My-6t; Sat, 22 Jun 2024 03:58:44 -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 1sKvdy-0002Ml-Qe for emacs-devel@gnu.org; Sat, 22 Jun 2024 03:58:42 -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 1sKvdy-00064w-IV; Sat, 22 Jun 2024 03:58:42 -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=iHy0gF7SOobihCxvQVTPJUnCp+3crR1psbq+7oYAkQs=; b=E5Sg6YltT3wcx4soeaoV y2WcrSjK6bx4zi3Vr0YO3ZlS4Iyb68zxyFgMnF32OwT6FoMm1yGhkNQR5hyHr3NQgbySZEIPFJZUs WGFvGpEiPtW3tySOSNl79/dfTXXBbnnz8sAphQbwoyPcaHEeY1wFZTTnI6t3FFl+XIK2eCZ/bsY5E dCNu4pcLq4ittSCS+xuydnQGMSA4qDieAMwiOyEkjt+urV5ir208aeTOx3BIgi0B06DM2S54fViw1 qJStSnHFZQgftghejd9f1pwK3ZY5wgLX6zXdROvUuqOBBku5MCSg7hkubDz46YMceFZx02+OF4CnT YbBMP+mI4E7w3g==; In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Sat, 22 Jun 2024 09:24:59 +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:320460 Archived-At: > From: Gerd Möllmann > Cc: Eli Zaretskii , Helmut Eller > Date: Sat, 22 Jun 2024 09:24:59 +0200 > > 1. Does igc really have to do something? I don't see something > noticeably growing, even after hours of using Emacs with igc. How many buffers did that session create and delete? Do you see killed buffers not collected (i.e. buffer objects whose name is nil that are not garbage-collected because the window's prev_buffers or next_buffers list references those killed buffers? That's what the comment in mark_window says: /* Filter out killed buffers from both buffer lists in attempt to help GC to reclaim killed buffers faster. We can do it elsewhere for live windows, but this is the best place to do it for dead windows. */ wset_prev_buffers (w, mark_discard_killed_buffers (w->prev_buffers)); wset_next_buffers (w, mark_discard_killed_buffers (w->next_buffers)); > 2. Is it an option to leaving these lists alone in GC? Isn't this the same question as 1, just IOW? > 3. If igc should do something, how frequently? IOW what makes these > lists grow? And perhaps could we do this cleanup where new entries are > pushed onto them? The growth of these lists is not the problem, I think. The problem is that they reference killed buffers, and that prevents those killed buffers from being GCed. > 4. Note that the loop in the function stops when a cons cell is marked. > So it doesn't always take entries off the list that contain dead > buffers. I don't understand that at all. I guess the cons cell being marked means that someone has a reference to it, and therefore it cannot be GCed?