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 19:48:31 +0300 Message-ID: <86ikzxo4v4.fsf@gnu.org> References: <877cghc0yy.fsf@gmail.com> <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> 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="9553"; 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 18:49: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 1s2D8q-0002Kp-Eb for ged-emacs-devel@m.gmane-mx.org; Wed, 01 May 2024 18:49:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2D8K-0004jC-3U; Wed, 01 May 2024 12:48: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 1s2D8I-0004ip-1t for emacs-devel@gnu.org; Wed, 01 May 2024 12:48:38 -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 1s2D8H-0002wM-PF; Wed, 01 May 2024 12:48:37 -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=/IX90V3ADfa9+rLACF2Mw9F1ifjBDIIx1QTrbB4Px/0=; b=IqbChkf+NpCxn96boBIM rl9YsM1Ve06Sv/Nb6gA1ifp+L7Yyyj/DAttpUOIuA/jFs5p3Vti+LJqapS7VlYmWDNOMGGSBUrAhj uNaI+4V/c9aXNPvP272EQIbHzeCnpQo5WCmUItw8hyOaf2FjXJlAR4SHn0iUdymjF9NjECYYJo8JY KQ1fS5q4kEzKV0Yodc5Shkrvuc4FaUuR2dDJQqMwGhNbcia2rwcVocvp/nur46fmG+2HFR6AvL5Q1 ulaAHEUjvqBqfuGh1DLwz7ZUDkQ0Gl6GMYrHzGS0aSCTL4zIxCQJVaz3LekP5JqFlNx0llQLlgy1K pdg55Wm5wdFV0g==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Wed, 01 May 2024 17:51:47 +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:318496 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Wed, 01 May 2024 17:51:47 +0200 > > > First, I don't understand why the above mechanism doesn't work. What > > exactly are the conditions which ensure that "ambig scanning of > > registers and the C stack" will work? > > The condition is: Some automatic C variable in the stack frames makes it > so that either the stack itself or a register contains the reference, in > this case a pointer to the string data (maybe interior pointer). > > That's not the case, or not guaranteed, for example, if we store the > string pointer in some global variable, in our case in a struct member > of a static array of structs. How do you see that it's a static array of structs? The way a coding_system is usually set when starting an encoding/decoding operation is like this: Lisp_Object code_convert_string (Lisp_Object string, Lisp_Object coding_system, Lisp_Object dst_object, bool encodep, bool nocopy, bool norecord) { struct coding_system coding; [...] setup_coding_system (coding_system, &coding); [...] if (encodep) encode_coding_object (&coding, string, 0, 0, chars, bytes, dst_object); else decode_coding_object (&coding, string, 0, 0, chars, bytes, dst_object); So the pointer to a 'struct coding_system' that is thereafter passed from encode_coding_object/decode_coding_object downwards (and eventually ends up in coding_set_source etc.), starts as a stack-based automatic variable at the top-level caller. Isn't that what we need for MPS to DTRT with any pointers to Lisp objects in 'struct coding_system'? > > Anyway: 'struct coding_system' is passed as argument to the functions > > involved in the en/decoding, and so is on the stack or in a register. > > If it's passed by value, we are fine. If its passed as a pointer we're > not because the char * in question is not an the stack. See above: it _is_ on the stack, right? > If it passed by value but was originally copied from a static > counterpart, we are probably not good, because that would copy the char > * from something we haven't traced. 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? > > Similarly for buffer text: the buffer object is a member of 'struct > > coding_system', which is on the stack, and the 'char *' points to the > > text of that buffer. > > Same as above for strings: if we're passing the struct around by value > etc. Is MPS tracing buffer text? I'm looking at fix_buffer, and I don't see where we do something with the own_text->beg there. Is that because the text is allocated not by MPS, and therefore isn't moved by GC? > > What if I do something like this: > > > > static struct window *my_special_window = NULL; > > void foo (Lisp_Object window) > > { > > my_special_window = XWINDOW (window); > > ... > > } > > void bar (void) > > { > > if (my_special_window != NULL) > > /* do something with my_special_window */ > > } > > > > IOW, is storing a pointer like above in a temporary global variable > > safe? > > You need to staticpro. > > 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. > >> I think the only thing you missed is why the automatic ambig scanning of > >> registers and control stack is not sufficient in Helmut's case (the > >> struct containing the char * etc.). > > > > Why is it not safe? I still don't think I understand that. > > It is the missing reference from the stack. DOes the above help somewhat? Depends on how you answer my questions and observations above.