From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Building the igc branch on MS-Windows Date: Sun, 28 Apr 2024 08:44:14 +0200 Message-ID: References: <86il063imh.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> <868r0yuhf1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24455"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 28 08:45:18 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 1s0yHm-0006AS-6B for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Apr 2024 08:45:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s0yGt-0004Da-Bq; Sun, 28 Apr 2024 02:44:23 -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 1s0yGq-0004DK-9F for emacs-devel@gnu.org; Sun, 28 Apr 2024 02:44:21 -0400 Original-Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s0yGo-0002QO-Lo; Sun, 28 Apr 2024 02:44:20 -0400 Original-Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-57255e89facso2316471a12.2; Sat, 27 Apr 2024 23:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714286656; x=1714891456; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tk5G0PwC9lxJ39y8kCgf7rXr8258fB104ArB0P27Wng=; b=Flbl1TSS8CJ3uILrpp48VKS+FZaCBltC8avUUO7m7B7V2V8NW12GLeYvtLuZvgMOOV VtKapIZyH6jC2Dlgx14ppHzw54ubCFX10LNhWUWUZKDPNZM38SVdCrRCF+PUuDICTmPg VjLog4nJHvT2aQxS2+CPihJMK6w1H8Iz/eMy1l1RuT+emJr1H26yVBV5STqONmRWquac 3Fk7gQnjxgzqP44oEWF9UY5ZkAScTtEAJdPVR1U2IRqj9kINuqsIuqISvH8Tz61jmXrk A/9L0mx2K1x9YKRwucu0eMD2gPTz+0VithJ1fYjeGk9YQMkzBOdWQBo0A8rWz+Ms0+Ij uwxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714286656; x=1714891456; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=tk5G0PwC9lxJ39y8kCgf7rXr8258fB104ArB0P27Wng=; b=bvBt2TeqIwNhutSSRA646RzDSjGtrQ4KMaaL1ytgKTS0ZEVk4eyzng6LyfgUNbcYZo beASFZEuOfaIkcllSfpXyF7WBnz8tvEQkO9JAVNcVOL6Ew/5CaS4Aivnjmxm6CFh8Oh9 Iv4Fyja2EoIwBCzSerC2VoU8Udin6Z4g8T5IArLh75JDqzV7YMgKzA9onesRhvp6Ig6j A8zX+SBGS0mj3HhVPeXvSSLvlDViff9FC4j0QEwaTk5V4TJ2prINv48SgMJxzFwX7A2g T+ih1EYg6uusoa3XAAmsstcmJsw9JOv0+43+0suz2HAV2wxro+h38Od+0h/SZytyMnmq eITw== X-Forwarded-Encrypted: i=1; AJvYcCXiyjThwMLYs0ZrTyVNDprPEWDoW0MPai5EIFUAFQfRfdMdp+neMGpjJpPO70Yb9DUespenBwO5xzjuUivYcn/3seqJ X-Gm-Message-State: AOJu0Yw9hM92vbjResq4OLyBdrHALC984bsYz9rbv4sgj9V8smKGnRYy gxFtnKJcttF/q2pyv682/tThOZSbfwBLk53bWv/l+z+fUTetJ5hCNuFY/Q== X-Google-Smtp-Source: AGHT+IESD3XvTASOgyXM9BOJifAu3c7UJGZISGbTwl8a3ek9p9rUNocwDb5GdZh3dgjrNxCnxsOCGw== X-Received: by 2002:a50:8e4a:0:b0:56d:faa2:789b with SMTP id 10-20020a508e4a000000b0056dfaa2789bmr2121263edx.40.1714286655436; Sat, 27 Apr 2024 23:44:15 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36a77.dip0.t-ipconnect.de. [217.227.106.119]) by smtp.gmail.com with ESMTPSA id y20-20020a056402271400b00572300f0768sm4707494edd.79.2024.04.27.23.44.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Apr 2024 23:44:15 -0700 (PDT) In-Reply-To: <868r0yuhf1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 28 Apr 2024 09:31:46 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x532.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:318233 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org >> Date: Sat, 27 Apr 2024 11:04:40 +0200 >>=20 >> > 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? >>=20 >> Ok, it's easy, and you already did TRT. >>=20 >> 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. >>=20 >> 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 =3D 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.) Ok. > 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? Yes, it is taken care of. MPS scans the control stack as an ambiguous root. It is more or less what the old GC does in that references found on the stack keep objects alive. In addition to keeping objects alive, ambif references also prevent moving these objects because we don't know if the reference is "real" or just a random bit pattern. That's the "mostly" in the mostly-copying idea, for which one could at one time get a patent :-(.