From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: MPS: struct window, prev_buffers + next_buffers Date: Sat, 22 Jun 2024 10:13:33 +0200 Message-ID: References: <861q4pjtn4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11326"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, eller.helmut@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 22 10:14:12 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 1sKvsx-0002jA-Ke for ged-emacs-devel@m.gmane-mx.org; Sat, 22 Jun 2024 10:14:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKvsS-0006uT-Nw; Sat, 22 Jun 2024 04:13:40 -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 1sKvsQ-0006u3-LG for emacs-devel@gnu.org; Sat, 22 Jun 2024 04:13:38 -0400 Original-Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sKvsO-0008SA-SB; Sat, 22 Jun 2024 04:13:38 -0400 Original-Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a7241b2fe79so1229766b.1; Sat, 22 Jun 2024 01:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719044014; x=1719648814; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=xtf7TJtSdYXgcsY7B+IfoANahvKTsdRn/MPl3/N6o7E=; b=P5EIswVztJpS+FS1YW+nuIEAso2CgU/PMo/1wR1nC+ARbvAJpWHDTqsSXeida/20hQ 9w8bNHFiT7RKlihWJL+pxQ1585NVtAsLaSTRU6nxIt/0e9IiswW6EGe6Zt12lT6UN23c 12pfl3BufXhR26/whKQzSMugsiVGeJ2rS+tCbkc1zDvbdYJQ0Uu6mLiJnuj4l6GoZKe7 z4zbsGMlt+FCig1YINsbblGaIkc9U1AT9Rr09ePxM/cTGZpc4pHtMwDx3ohXKJ3afaJ6 3BdhsQZ1wY2WqyaUUlzeQdMmQQ0BU8fOnuZTymCa4ChbXvJM0M7AiCpMAVjXHattqDAx rLug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719044014; x=1719648814; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=xtf7TJtSdYXgcsY7B+IfoANahvKTsdRn/MPl3/N6o7E=; b=hF7Bz++A6DlyRPeL0eDbEvAQ4Izm4aDaRdUVZR2RHTmQA2aOpX/NqgKTQoHdVKy5DI BzO030LaD5ir0V4d1Qi8hzCr/ggbOhj/tQ5UgNtuv3qqmOcpQDtXB7ha5Jhn33FJfg34 Pgcd9hf5tme+kn/6q3xj00wdM56rlDxCnCws+y5ANKHeFAWFWhkWO2UmDUxtSle3Yesq oczAmoWkh/VYtHsMrY0xQghXbThrTGuL1smm3ziM2EKGCdJrHPPNn15eJ2qeny4NWwlQ 01CSWOlRQMotdcR1fpaXjTKxTDoXKaqRfxBomXsxLhVuUQApZkx7QIAmEBbvgJAegdAe /vxQ== X-Gm-Message-State: AOJu0YwmRIbyQ0Ft2CpEWiK4kzVpZ6IM+55TX5QLQfnHnofwv6m++syV Ku3tral9qP4W1lDTrPOQqSGHI4Oi3wwj3T7RLx+4luKmytDOaSybxyRoxA== X-Google-Smtp-Source: AGHT+IHIKAnK44mmuIDs5zV8v7EQQB5QTt22Uc3KSwRYaFPqOIV6kjrz4PHvm8SA9qPkrB5oNL5irw== X-Received: by 2002:a17:906:fe44:b0:a6f:96b0:ed2 with SMTP id a640c23a62f3a-a6fab61c269mr801069466b.30.1719044014473; Sat, 22 Jun 2024 01:13:34 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e364bf.dip0.t-ipconnect.de. [217.227.100.191]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6fcf549278sm166223666b.103.2024.06.22.01.13.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Jun 2024 01:13:34 -0700 (PDT) In-Reply-To: <861q4pjtn4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 22 Jun 2024 10:58:39 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::633; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x633.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:320461 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Eli Zaretskii , Helmut Eller >> Date: Sat, 22 Jun 2024 09:24:59 +0200 >>=20 >> 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: How many buffers get killed is hard to tell. I have usually 50-100 file buffers, which are kind of long-lived, plus constantly temp buffers (I guess) that are created by vertico and alike. I've not noticed that the number of buffers increases noticeably. There is always some variation that I would expect from conservative roots, of course, control stack and alike. Maybe it's because windows aren't long-lived? No idea. > > /* 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? Maybe :-) >> 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? But it won't be GC'd anyway, becuase it's marked. And if the buffer in the cons is killed, it remains in the list. That makes no sense to me.