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 18:12:25 +0300 Message-ID: <86cyq4l02u.fsf@gnu.org> References: <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> <86ikzwl8ih.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="21212"; 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 17:12:45 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 1s2Y73-0005I9-2s for ged-emacs-devel@m.gmane-mx.org; Thu, 02 May 2024 17:12:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2Y6q-0003AY-Ty; Thu, 02 May 2024 11:12:32 -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 1s2Y6n-0003AI-U3 for emacs-devel@gnu.org; Thu, 02 May 2024 11:12:30 -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 1s2Y6n-0002XU-Fi; Thu, 02 May 2024 11:12:29 -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=D+0/vHYUHB+gsrZqWsJTQK3AlYQzHctpYZx7vylw5Hc=; b=ikQFmtla4l6MU21TndTU QwyqhJlgbD7JAkWfQ7Qnd7siLim8Unri1m1EPpzJroVWve6WRqyN7GYVt49RoNyusPYaNLQEIp6OS YBPFqDyUUJ7aQDuS1jw2fgRpn+Fhp2A6bBZq01oL25N3HDSi/z/Igb7aOvFn3jb2UsDYFiyAiIJ0z hIBqNwtQ45gwLEgcpynaGkBcvergXdKLxUglEn5IsP7k6Dq+1DmrNorCi+M+EEuQvtGCS0EyzBHDi DaRZJjKq5K4579tfuwCRy8ja4Qhs6jARxAUm2BlJ9tIyzFpfH+GzEXPO+ob7EFM8aevhr5814FQnF j0cbdqU8hP0WmQ==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Thu, 02 May 2024 14:30:01 +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:318583 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Thu, 02 May 2024 14:30:01 +0200 > > Eli Zaretskii writes: > > >> > 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. > > Right, that's true. So it's another complication. Right now, the function that "frees" the cache is very simple and fast: static void bidi_cache_reset_to (int n) { bidi_cache_idx = bidi_cache_start + n; bidi_cache_last_idx = -1; } static void bidi_cache_reset (void) { bidi_cache_reset_to (0); } If we go the igc_xzalloc_ambig route, then not only will we be wasting CPU cycles on zeroing-out of the cache each time we (re)allocate it, but we will also need to waste CPU cycles on zeroing them out in the above functions. If that can be avoided, I'd prefer to. > >> 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. > > Yes. That should be very easy to do, then. Can you tell me how I make a struct unmovable by MPS, when I have a pointer to the struct in hand? > I now wonder: If struct it always lives on the stack (I think that's still > true?), then it->w is also on the stack, and thus it->w is immovable by > fact fact. Right? Yes. So you are saying there's no problem, neither with it->w, nor with it->bidi_it.w, and thus the cached bidi_it objects are also safe in this aspect?