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: Some experience with the igc branch Date: Sat, 28 Dec 2024 12:07:33 +0100 Message-ID: References: <87o713wwsi.fsf@telefonica.net> <86ldw40xbo.fsf@gnu.org> <868qs329kj.fsf@gnu.org> <864j2r25hg.fsf@gnu.org> <861pxv234y.fsf@gnu.org> <86zfkjznat.fsf@gnu.org> <86ldw2zy6s.fsf@gnu.org> <867c7lw081.fsf@gnu.org> <86cyhcum5d.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="778"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: stefankangas@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 12:08:09 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 1tRUfw-000Abz-Dk for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 12:08:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRUfY-0005X0-BX; Sat, 28 Dec 2024 06:07:44 -0500 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 1tRUfW-0005Wr-UC for emacs-devel@gnu.org; Sat, 28 Dec 2024 06:07:42 -0500 Original-Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tRUfU-0005hx-SO; Sat, 28 Dec 2024 06:07:42 -0500 Original-Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-aae81f4fdc4so1142405966b.0; Sat, 28 Dec 2024 03:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735384057; x=1735988857; 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=LQAm+tm0Nq6Rdkc+36zYgbU+EOnu+6G0/hDPesVzsxI=; b=jhEFbzqLOvC2tKKa11oqDopqnucs3epUjxBCqO+QxrUJxqfUjJYe6kTnBVHdy2bLbV V/d6a5zHVz1HmAqM7kcz7XOw2+bqgGZKQDDsh0yiUJ96ZR8Xp8icxH3BR6Wkcn7L/8PQ 9zkUyPbyfpAy0bi10B2Z0fj1EgeVoPaVtCr3pC7AB+Ijixha5LM1Pwvykz/7hhHTbbZL DmM8XGYdN+8Os2Efoib4jKxwjFlBPJk37mUDWXhNwI6kevObcYhZrlJeRKADfO+ZWO5c NaHFx1HUnWIrfuQic2lGGigdLWiOzmH1TAPfTHjS/aRjkubeecRL9k2C0vfrZiMp5BIX Wtgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735384057; x=1735988857; 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=LQAm+tm0Nq6Rdkc+36zYgbU+EOnu+6G0/hDPesVzsxI=; b=UFsIs4U9N90tVe8yaXEubZ4YFwMUu84lhLngzG7f9q5crfRRVfyHd2mEdop9FI8rDu JFRjCLwDuQGPhkCKYcigtk340OMMuP5LJ9dMh+ZesybEDEZzNG6y2gYpbJnbKsCci4jJ UR83MdezCU1SQqgJ+8TieIBurkdANF3NY+pzCIFwsMDdgpwWEamFo8mDZxv9hqyt0v6k UHKBYgC+eLsoEzjTWBMNOfqeK0ePFDtl2lKCI+NDYIjYD24DRGcQB5JEqBU1/N4Fn/QC uxM/PzuGASm2jakHDrlsl0AOUO6Y/f/fKsCuHDYREuO88jLTgdeA2swKtj0KyU036RNV qN0g== X-Forwarded-Encrypted: i=1; AJvYcCVZgdAHpM7MoeCMotzK3WLFKxOeOGq1VJvy6134OeMRvRrbvZPPoyrWfBGlkpE6pdq8dYpb7+DHmg==@gnu.org, AJvYcCXx5baMsPG/M1VgY18CSVqFiU9OGlTsOIZAxUdK7fssQHbz5FiXne3QzksPgpag/9fMaE4Y3zLGyTt3qAI=@gnu.org X-Gm-Message-State: AOJu0YzIaVSBL5i/09IBPMmHaFhgvFieAkK4+LT6SJklusekPcx118bC Bz7HxcXQaQN7M6FMU4zodY60Se4H74aryHQQeHeh+Zgiie0FSYOZgQT5dQ== X-Gm-Gg: ASbGncvUzSKZE9S/CBO7EmOsVK15Ms/0+YHwIF6uVxVz2E1rozY3T45TCqk5RBBrSxb Q6hMA6wXdGZU+w9mhPd5/wD/a9cOpNkgNuozUrQ5ZFQEtNqHQgVeD17fNpZKLUQp4kq1d9Y5AtN RQzT0rzO0SHgqNnxYKwB7iKeRepD5i/ZgsIlEPblo4T6hm1aMjmsv4xfYmbh/0AhYIb7uGndMur vRMuRf2JzY9y0jK4hF+LDlRT62H6TK9PNDoQmS/s1sLCsmdfubg3I8H6A2JfSKYETAA7TI4QR6q eGaD+5UkUBTE9RCqLYTG5nRajpldz+QCqrGypLwJVBNfYRNB/gKLVSavTX2UUdeQXA== X-Google-Smtp-Source: AGHT+IFXagOKODuS/z/GWNBzUC2ktdbGebKrWx+FtBtUca/4TDgxEwwDkSyxERg/NhtQdeQ3jwIcdg== X-Received: by 2002:a17:907:d93:b0:aab:eefd:bfd8 with SMTP id a640c23a62f3a-aac33790c31mr2509301566b.49.1735384056510; Sat, 28 Dec 2024 03:07:36 -0800 (PST) Original-Received: from pro2 (p200300e0b706e400c44cad3d21adb953.dip0.t-ipconnect.de. [2003:e0:b706:e400:c44c:ad3d:21ad:b953]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e894c18sm1232280166b.48.2024.12.28.03.07.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Dec 2024 03:07:35 -0800 (PST) In-Reply-To: <86cyhcum5d.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 28 Dec 2024 12:39:26 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:327252 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: stefankangas@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es, >> emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org >> Date: Fri, 27 Dec 2024 19:21:30 +0100 >>=20 >> Eli Zaretskii writes: >>=20 >> > - Concurrent. The GC runs in its own thread. There are no explicit >> > calls to start GC, and Emacs doesn't have to wait for the GC to >> > complete. >> > >> > Pip says this is not true? I also thought MPS GC runs concurrently in >> > its own thread. >>=20 >> What Pip said was very easy to misunderstand, to say the least :-). No, >> MPS is concurrent, period. There are situations in which MPS can, in >> addition, use the main thread. And it's still concurrent, period. > > How can you see which thread runs MPS? Where should I put a > breakpoint to see that (IOW, what are the entry points into MPS GC > code)? If I run Emacs with a breakpoint in process_one_message (after > enabling garbage-collection-messages), all I ever see is GC triggered > by igc_on_idle, which AFAIU is only one of the way GC can be > triggered. Where are the entry points for the other GC triggers? I'm > asking because I'd like to run Emacs like that and see which thread(s) > run GC. I wonder if your interpretation is right here. AFAIR, process_one_message is always called from igc_on_idle. IOW, we handle messages from MPS only when Emacs thinks it's idle, and that is always in the main thread. The messages are produced and put into the MPS message queue in the MPS thread, usually. Or maybe, I don't know that for a fact, also in the main thread, when allocation points run out of memory, or when we do an mps_arena_step. The arena step thing is only done if igc-step-interval is non-zero, which is not the default. (I'm personally using 0.05 =3D 50 ms, BTW.) How to get hold of the MPS thread I don't know. I just see one thread more when using igc than with the old GC. Maybe one could sett a breakpoint on that ArenaLock others mentioned, with the warning that I don't know what I'm talking about when it comes to MPS internals. > >> > When copying objects, a marker is left in the original object pointi= ng >> > to its copy. This marker is also called a "tombstone". A "memory >> > barrier" is placed on the original object. Memory barrier means the >> > memory is read and/or write protected (e.g. with mprotect). The >> > barrier leads to MPS being invoked when an old object is accessed. >> > The whole process is called "object forwarding". >> > >> > This doesn't tell how object forwarding works once triggered by access >> > to protected memory. Can you say something about that? >> > This: >> > >> > MPS makes sure that references to old objects are updated to refer to >> > their new addresses. Functions defined in the object format are used >> > by MPS to perform the lowest-level tasks of object forwarding, so th= at >> > MPS doesn't have to know application-specific details of how objects >> > look like. In the end, copying/forwarding is transparent to the >> > application. >> > >> > seems to try to explain that, but AFAIU stops short of telling it. >> > IOW, how are "functions defined in the object format used by MPS to >> > perform the lowest-level tasks of object forwarding"? >> > >>=20 >> I'm afraid I can't describe that in detals because it's an >> implementation details of MPS itself. AFAIK, it's not documented, and I >> don't read the sources of MPS. >>=20 >> Object forwarding in general is not specific to MPS. Many copying >> collectors use it. I tried to explain this as far as I could without >> knowing the MPS implementation. >>=20 >> Whether one should describe this in detail here is a valid question. >> Maybe someone knowing the MPS implementation in detail could add that. > > I'm only interested in this insofar as it's relevant to the functions > defined in igc.c. E.g., do any of the "scan" or "fix" function have > anything to do with object forwarding? If so, I thought it would be > useful to describe that, to help people understand the role of those > functions and what their code needs to do. MPS_FIX2 has to with it because it returns an object's new address which we then can store where we got the old reference from. See fix_lisp_object. Do you think mentioning that would suffice? >> > MPS allows us to specify roots having tailor-made scan functions that >> > Emacs implements. Scanning here refers to the process of finding >> > references in the memory area of the root, and telling MPS about the >> > references. >> > >> > What is the purpose of "telling MPS about the references"? >>=20 >> If MPS were the old GC, it's like letting MPS do its mark_object. >>=20 >> What about if it said "... telling MPS about the reference so that it >> knows the references object is live", only expressed better? > > Sure, that's much better, because it makes this much more concrete. =F0=9F=91=8D