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: Building the igc branch on MS-Windows Date: Sun, 28 Apr 2024 09:31:46 +0300 Message-ID: <868r0yuhf1.fsf@gnu.org> References: <86il063imh.fsf@gnu.org> <86ttjp20je.fsf@gnu.org> <87y191fwnd.fsf@gmail.com> <87cyqcfv6k.fsf@gmail.com> <86o79wzi31.fsf@gnu.org> <86mspgza23.fsf@gnu.org> <867cgkz7e2.fsf@gnu.org> <87r0esdv7o.fsf@gmail.com> <87le50dmec.fsf@gmail.com> <8734r7etu1.fsf@gmail.com> <86il03xrlz.fsf@gnu.org> <868r0zxpfr.fsf@gnu.org> <861q6rxnst.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="1468"; 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 Sun Apr 28 08:32: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 1s0y54-00007R-57 for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Apr 2024 08:32:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s0y4o-0001nw-AY; Sun, 28 Apr 2024 02:31:54 -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 1s0y4m-0001mV-HI for emacs-devel@gnu.org; Sun, 28 Apr 2024 02:31:52 -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 1s0y4m-0000a3-7t; Sun, 28 Apr 2024 02:31:52 -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=rfT3McVLM0BCSYF7cuVp5w8ojC1S+yjkNjg5RPpXJcs=; b=pzbqhMyIxizmk9J7ZOpa jCEgDarLSzDgcvcif/ua80Sbl7KrDJqnZwqTHOuEqD1172P4k+phvkykqFCAg15m8iumwkQa3+ujP 6M7Vq5y14yNqJaJy7C4k8z75wK3d1yLMBUWgtrogTXxqE67N4cerIwMunye6r5rDrZmUmZBnYUuiS mgz3eKKSN7VUSPmD+PeBGl4eb768sYqQDN/KkT2BUGND9L+xurypPHNyQ4W0F4K+Zc06r7Ut4h4pH ibXUxhL4kj29bXFLGOmG+L0YsB+HKJqW6AJMlGI097Y2hO4y4QuqUjPRWnhuuOA89ivilD82u+SOz QukomzdxLN7yNQ==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sat, 27 Apr 2024 11:04:40 +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:318232 Archived-At: > From: Gerd Möllmann > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > Date: Sat, 27 Apr 2024 11:04:40 +0200 > > > If some of those are not needed to be scanned, then maybe I don't > > understand the criteria for scan-ability? Would you please explain > > the basics here, like MPS 101 thing? > > Ok, it's easy, and you already did TRT. > > References interesting for MPS are Lisp_Objects and pointers to objects > in MPS. The need for tracing pointer references is new compared to > non-MPS. It must be done because objects move in memory. > > Tracing pointers to non-MPS objects is not necessary. Ideally, it costs > only some cycles. At least that's my understanding, that it does no > harm. Let me understand the meaning of this for our usual Emacs coding style. We use the following paradigm _a_lot_: struct window *w = XWINDOW (some_window); /* ... much later ... */ do_something_with (w); (The do_something_with doesn't have to be a function call, it could be some comparison with another 'struct window' pointer, or dereferencing w to access some field of 'struct window', etc.) Given that now the some_window object can move in memory as result of GC, what does it mean for code like above? Will MPS magically update the pointer in w to point to the new location, or use VM protection to redirect any accesses to the pointer in w to the new location? For that matter, can GC even happen between XWINDOW and do_something_with? Since GC is (AFAIU) asynchronous and runs in another thread, what can trigger GC while the Lisp thread runs code like above? Do we now have to be cautious with accessing Lisp objects via their C pointers, like we did until now with Lisp strings and buffer text? Is the above a real issue, or is it already taken care of for us by MPS?