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: staticpro everything Date: Thu, 02 May 2024 15:10:14 +0300 Message-ID: <86ikzwl8ih.fsf@gnu.org> References: <87ttjlabic.fsf@gmail.com> <87v8408wsr.fsf@gmail.com> <87o79sasl5.fsf@gmail.com> <87plu72y8h.fsf@gmail.com> <877cgfwe5g.fsf_-_@gmail.com> <871q6mptkj.fsf@gmail.com> <86frv2pse5.fsf@gnu.org> <87v83ynhuc.fsf@gmail.com> <86v83xof5w.fsf@gnu.org> <878r0thbfl.fsf@gmail.com> <86jzkdo9rm.fsf@gnu.org> <87jzkdfres.fsf@gmail.com> <86plu4mylj.fsf@gnu.org> <86msp8lbci.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="37601"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, emacs-devel@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 Thu May 02 14:11:25 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 1s2VHY-0009Vo-PB for ged-emacs-devel@m.gmane-mx.org; Thu, 02 May 2024 14:11:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2VH2-0003Gt-Nr; Thu, 02 May 2024 08:10:53 -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 1s2VGu-0002zE-9l for emacs-devel@gnu.org; Thu, 02 May 2024 08:10:46 -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 1s2VGs-0000Mh-1M; Thu, 02 May 2024 08:10:43 -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=QwQ9sWtAWjd6uQw7b43Gb3N+GuKK5xAu0DSflPT8lcM=; b=aqrxY/iVczTUIcRTn2M3 tcpIbaWn7ZamC1vskjCemJ5OPniLsZae2HpjH2noeUUlHyCtUn9GTTF5QnG5sKqG1qboVQZovkX7k 9KWfUSc0BERB9jz1ndn8zHti7NRWi9oeUfrpP0/mmBtHieUGjwJ2AaAKt4xDLPiTFx4Jvro1lIQRg VFBSsyVkIyaJHYTpiU/rMRrauRcwfq7JzE16nZ2g0AixBoom6TzXPdpo/Vi9V+8pPkTpx0vnNJaij EebWhwisCyp7B8vCZChVLSTFtZcZNiDAca30Ck62Rt4CajpGs0kZnhNLgel0Ka9aYw5ZhtTEFbNI7 QyLZPibw//tFQg==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Thu, 02 May 2024 14:01:18 +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:318571 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Thu, 02 May 2024 14:01:18 +0200 > > Eli Zaretskii writes: > > >> I would propose to use igc_xzalloc_ambig + igc_free in the MPS case > >> instead of xmalloc/xfree. There are also realloc, and palloc variants, > >> if you use that. > >> > >> This is the same as the normal malloc/free, but it also adds an ambig > >> root, so that anything references from the malloc'd memory becomes > >> immovable / doesn't die. It's the same as if that memory would be part > >> of the control stack. > > > > But doesn't that mean MPS will need to trace too much? > > Yes, admitted :-). We could optimize that later... It also means (AFAIU) that every cache slot that is "freed" by moving bidi_cache_idx back will need to have the 'struct window *' member be set to NULL, to prevent MPS from tracing garbage. Right? I'd like to avoid these complications, if only for performance reasons. > > Also, does the above mean my idea of making the window unmovable is > > not good? If so, can you explain why not? > > I'm sorry, I don't remember. What was the idea again? Make it so the window being processed by redisplay_window is unmovable. That is the window whose pointer bidi_it uses. But I also think doing this will be useful for other reasons, since the display code manipulates the it->w pointer quite liberally, and who knows what we do with it? If the window cannot move while it is being redisplayed, we can stop bothering about all those uses of its pointer.