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 19:24:22 +0300 Message-ID: <868r0skwqx.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> <87sez06yj3.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31640"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 02 18:25:56 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 1s2ZFr-00081U-6z for ged-emacs-devel@m.gmane-mx.org; Thu, 02 May 2024 18:25:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2ZF6-0003X9-Fh; Thu, 02 May 2024 12:25:09 -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 1s2ZEv-0003V5-5Y for emacs-devel@gnu.org; Thu, 02 May 2024 12:24:58 -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 1s2ZEu-0008FA-B3; Thu, 02 May 2024 12:24:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=UwSvCnWegdj5BfljEyh9RcMfb2y2DOBWgCDdZeQiN60=; b=Ju1TgGUgT4Rm SK1DMhgvEQul9bhFVodOnBQgbXR5KF0uJYnqivaf+NhO8McjybEotYdrWwg1nf027GXzOJkdLcTKc qyFFuaJqS6yDTulA0VTMHlrxnf24vjeMvhNk9XWtGZZpEiwRHie7rr2fl3AfL4LPGQOm6yfm8TODw xcwxOjj9KqfRDflfYu755ip1J0J9DtCZeh0QxfHINvykkyVBsG9ncEln05r7XKVsd/80YX2IAAADz Iahj/Mk0XlC4WgqX3xtgoess2b4DF90tFcNPXqbtyzK0fyBwlYcTZtsU/EdbmZOojnbV6y7xv337o 81nfqJfr9tAACxYw/yZRxA==; In-Reply-To: <87sez06yj3.fsf@gmail.com> (message from Helmut Eller on Thu, 02 May 2024 17:09:36 +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:318593 Archived-At: > From: Helmut Eller > Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org > Date: Thu, 02 May 2024 17:09:36 +0200 > > On Thu, May 02 2024, Eli Zaretskii wrote: > > > I hope the above provides a clear overview of what the cache does. > > Yes. I wonder though, why there is a pointer from the cache to the > window a why it is not the other way around. At the lowest level of bidi.c, it accesses buffer or string text to fetch characters. But if the buffer/string position being accessed has a display string or overlay string covering it, bidi.c needs to know about that, because display strings and overlays are treated specially by the reordering algorithms (I can tell the details if needed, but for now I will omit them). And overlays can be window-specific. So the code which searches for overlays, which is called from bidi.c, needs to know the window. This explains why strict bidi_it has a reference to the window: so that code in bidi.c could use it when necessary. Why this reference to the window is in the cache is simply because we cache the iterator states by copying struct bidi_it into the cache almost in its entirety. I guess if really necessary, we could avoid copying some parts of struct bidi_it, like the pointer to the window, because the window doesn't change during the iteration, so it doesn't depend on the iterator state. But bidi.c implements copying into the cache with memcpy, and at least at the time it was very important to me to keep the code as efficient as possible, which meant the speed of memcpy trumped any other considerations. > BTW, there is also a Lisp_Object in bidi_string_data, and apparently > one of those borrowed char*. Right, I hope I explained what those are in my other message. > I also have put the "staticpro everything" task on hold. I think we > learned that protecting more globals than is done for the old GC is > rarely needed and may cause more harm than good. Those cases were it's > actually needed, will show up during testing. Fingers crossed.