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 GC and its implications Date: Wed, 01 May 2024 20:52:29 +0300 Message-ID: <86frv1o1wi.fsf@gnu.org> References: <86jzkhu5rv.fsf@gnu.org> <87ttjlabic.fsf@gmail.com> <87v8408wsr.fsf@gmail.com> <87o79sasl5.fsf@gmail.com> <87plu72y8h.fsf@gmail.com> <877cgfwe5g.fsf_-_@gmail.com> <871q6mptkj.fsf@gmail.com> <86wmodofvw.fsf@gnu.org> <86o79poa7r.fsf@gnu.org> <86ikzxo4v4.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="2512"; 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 Wed May 01 19:53:10 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 1s2E8k-0000QV-5F for ged-emacs-devel@m.gmane-mx.org; Wed, 01 May 2024 19:53:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2E8A-0007DP-9G; Wed, 01 May 2024 13:52:34 -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 1s2E89-0007D2-0R for emacs-devel@gnu.org; Wed, 01 May 2024 13:52:33 -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 1s2E88-0005OA-Mo; Wed, 01 May 2024 13:52:32 -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=Ov+H8JbmtS8j51XLaTqy1xV36R3l1hwHczucJKd9DOA=; b=cwySk3xarkhFRiwz4a6n a+uEDGwtIelkG2f0MHkbIpx+iEIAGIl1hS/L6MY9Jaz3YG4Na5DSbPpolo/dES1N0Mgb+ooGFIcWW 29Is1yTp05Z+A1Ay3vXoPBQAv8nOEnhnIhzIidK8hXPEwP1RjJyUPtchroh1j1NCM3jmiobEw3Ckf iv+MUnly403oJNuImLVDgmxwZ1CZFsGQ39uhAMv6dr/fw2A57cUW9oVS4hDN3v705Vgc8U55TU2e/ GR6bEZy4r+LKrZPWpewegc6hB4PnrHa0+NdRIqiZZ6A+nlBaS1u4QU0cfn7Oxu75XbOtdbsh9Do0y T/RkCsbcUzAGZA==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Wed, 01 May 2024 19:17: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:318502 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Wed, 01 May 2024 19:17:01 +0200 > > Eli Zaretskii writes: > > > How do you see that it's a static array of structs? > > a326d6aed816c19f66729a7ff77d90ef6bcec07c > Author: Helmut Eller > AuthorDate: Tue Apr 30 11:04:54 2024 +0200 > Commit: Gerd Möllmann > CommitDate: Tue Apr 30 20:59:38 2024 +0200 > > Parent: 44100e5b081 Add missing #ifdef HAVE_MPS > Merged: emacs-29 > Contained: scratch/igc > Follows: igc-first-commit (76) > > Staticpro coding_categories > > * src/coding.c (syms_of_coding): > > 1 file changed, 10 insertions(+) > src/coding.c | 10 ++++++++++ > > modified src/coding.c > @@ -11848,6 +11848,16 @@ syms_of_coding (void) > > Vcoding_category_table = make_nil_vector (coding_category_max); > staticpro (&Vcoding_category_table); > + for (size_t i; i < ARRAYELTS (coding_categories); i++) > + { > + struct coding_system* cs = &coding_categories[i]; > + Lisp_Object *src = &cs->src_object; > + *src = Qnil; > + staticpro (src); > + Lisp_Object *dst = &cs->dst_object; > + *dst = Qnil; > + staticpro (dst); > + } > /* Followings are target of code detection. */ > ASET (Vcoding_category_table, coding_category_iso_7, > intern_c_string ("coding-category-iso-7")); I'm not sure I get your point. The contents of coding_categories[] is AFAIK never used to actually encode or decode something. It is just a handy db of known coding categories for using in all kinds of APIs that need to examine the known categories for some reason or other. > > I thought we agreed that all the global variables with Lisp objects > > need to be staticpro'd, didn't we? If we do that, we are covered for > > anything that comes from there, no? > > See the commit at the start. It seems coding_categories isn't > Lisp_Objecut and thus cannot be staticpro'd. I'm not sure I understand why we need that loop. The src_object and dst_object members of coding_categories[] is AFAICT never used anywhere. The values of src_object and dst_object were AFAICT never set in the elements of coding_categories[], they are only set now by that loop, and for what purpose? just so we could staticpro them? In general, these are coding categories, not coding systems, AFAIK they are just stored as coding-systems because that's convenient. > >> It's basically like with the old GC. Nothing makes sure that the window > >> has survived when bar is called, withput staticpro. The difference to > >> the MPS GC is that my_special_window might have survived in the old GC > >> because something else keeps it alive and that is all we need (fond > >> memories of GCPRO, booooh ;-)). > > > > The old GC didn't move objects. So the window could have been deleted > > meanwhile, but its 'struct window' couldn't have moved to a different > > address in memory. > > Hm, I don't understand where you are aiming. I find the code is > incorrect because nothing really guarantees, in code, that > my_special_window is live when bar is called. Unless we staticpro. staticpro doesn't guarantee that the window is live, either. Unless we are talking about two different meanings of "live". What I meant by "live" is a window that was not deleted meanwhile; that can be tested with WINDOW_LIVE_P. The old GC didn't delete windows; if a window was live before GC, it would still be live after GC, and its 'struct window' will be at the same address. By contrast, with MPS a live window could move to a different address, so my pointer will no longer point to it after GC.