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: Fri, 03 May 2024 15:01:00 +0300 Message-ID: <86fruzhzpf.fsf@gnu.org> References: <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> <87r0ektkfo.fsf@yahoo.com> <86frv0l0ir.fsf@gnu.org> <86bk5okxfl.fsf@gnu.org> <867cgbjs1q.fsf@gnu.org> <87v83vnnxz.fsf@gmail.com> <86jzkbi15c.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="16080"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, luangruo@yahoo.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 Fri May 03 14:01:44 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 1s2rbj-0003wy-Dd for ged-emacs-devel@m.gmane-mx.org; Fri, 03 May 2024 14:01:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2rbF-00042O-Tz; Fri, 03 May 2024 08:01:13 -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 1s2rbB-0003zM-LP for emacs-devel@gnu.org; Fri, 03 May 2024 08:01:09 -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 1s2rbB-0003tu-B0; Fri, 03 May 2024 08:01:09 -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=EsLhLs5Rca97y72dzaTumjEd158pkUup+WcuzuSPUEE=; b=cJQQrWg6dn8eeTUjGbxV AO7I/ZDStSTtY0fEa9ZVud3T70l9Hw+S/F30LpHjRt/IZUnWlAMbaGGKmsKZ567aTBdtHp8KNi43w u9E4q0i/6Q3jNIwkuhxkf7l9UWnHjbKAh+MB/6KV+d+9kNBOKiAANWSel4s1MXsVHpR+X4SvN4Nnh sPBDFbL8IJKRY42zoW4vyXqUHInFAm9veK1Kw5KKdHz/LpoGMvckNsJrPxXkLaI90GGWn1ac8eI6u EirNVIU5wERkH2a/OVmIQHMGZ+B55V1YaBloiHa6iEvq5X5PDQBNkshbGa7/vWxYwzjLTdWLxOEHb yI10DwBM9X6XMw==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Fri, 03 May 2024 13:49:51 +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:318669 Archived-At: > From: Gerd Möllmann > Cc: Helmut Eller , luangruo@yahoo.com, > emacs-devel@gnu.org > Date: Fri, 03 May 2024 13:49:51 +0200 > > Eli Zaretskii writes: > > >> From: Helmut Eller > >> Cc: Eli Zaretskii , luangruo@yahoo.com, emacs-devel@gnu.org > >> Date: Fri, 03 May 2024 13:18:32 +0200 > >> > >> > That leaves the u.s.data, which is an object that is not on the stack > >> > but only referenced from a string that is on the stack. > >> > > >> > That always works because to do anything with u.s.data, the CPU must > >> > load that pointer into a register or somewhere on the stack. By that > >> > fact the same applies to the string data that applies to the string > >> > above. > >> > >> Is it so easy? Somebody could load &u.s.data into a register but then > >> quickly stow it away in a malloced struct or a "temporary global > >> variable". > > > > I also don't really understand this. AFAIU, it is not enough to have > > u.s.data pointer in a register, we should also be sure MPS will update > > the pointer with the new address if and when the string's data is > > moved. But how do we know MPS will have the opportunity to do such an > > update? the Lisp thread could use the (outdated) pointer before MPS > > has the chance to update it in the register. Or what am I missing? > > I think you're overlooking that registers and stack are ambiguous roots. > The presence of u.s.data in a register or on the stack _prevents_ it > from moving. That doesn't resolve the difficulty, it just turns the table. Now we could have a race condition between the Lisp thread loading a pointer into a register or pushing it onto the C stack, and the MPS thread taking a notice that the pointer is in a register or on the stack. If the pointer was neither in a register nor on the stack when MPS started GC, it could decide to move the object, while the Lisp thread concurrently loads the pointer into a register. So we might think the object pointed to is unmovable while it isn't. What am I missing now?