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: Wed, 25 Dec 2024 15:57:32 +0100 Message-ID: References: <87o713wwsi.fsf@telefonica.net> <87a5cnfj8t.fsf@protonmail.com> <86seqe4j4f.fsf@gnu.org> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> <868qs329kj.fsf@gnu.org> <864j2r25hg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25551"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 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 Wed Dec 25 15:58:24 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 1tQSq7-0006W6-Eg for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 15:58:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQSpQ-0000Me-UU; Wed, 25 Dec 2024 09:57:40 -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 1tQSpO-0000MU-Rj for emacs-devel@gnu.org; Wed, 25 Dec 2024 09:57:38 -0500 Original-Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQSpN-0003uK-A1; Wed, 25 Dec 2024 09:57:38 -0500 Original-Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-aa6c0dbce1fso828452766b.2; Wed, 25 Dec 2024 06:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735138654; x=1735743454; darn=gnu.org; h=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=sl0H6ruFt+Wfk3xv1xcB2ylk3tQTr4hgruafGzkQqHI=; b=BRIqUj/xd1NAnFMmmssThQD1rMx+sG0buoY0xX5sH2VCWT1fAkbsePaiR40mn7p0dK eY/vcjcETOJvs9gqC+JcmCbq6Yit/trmYSYSeMlxrKHCGw6AjJs18e6hh1f7ehUOgQPz xyfVMWR4t4liq+wGat/1CHzkb4pgv900UGp/Z8222FZ1B068SbETGM0tlBWziExHtpuP NoHPZGJuw622tCmnuzkaVB6cS1wYOE7Qjx24fgF1qBKJN3Ti46W/CSE4TqFkNiilUB4Q IZSQE0itjpVVI2Y1kLfoC/Eu6XDYvr5NTDP59CGuG++z1sPfrwusNyGAGzJrmgB1LZrY i8bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735138654; x=1735743454; h=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=sl0H6ruFt+Wfk3xv1xcB2ylk3tQTr4hgruafGzkQqHI=; b=WZkz05BQMrZjzoZUNFlvg7FCEI3xQyuuu26h8+IjRgTq6DTcox0VvYuQEwMJ+/180A 2hw6FuJu1Zjt7G6Gf65HYTYSu+OyCGlV0SSwoBP6+l/DspEnjonsBoCwNWoeCitna4PB 1xe3JNhHT1+FuoVl52h731uwJIT8jaVdQ/fyxxRjTm57z7bltIchM16pXIt6Ir6i8NCZ gU/f0UT+WKU2EY+Ya5L/lzKnGIblc/2USrt17h/ozefF8TcPNBOZlIdEmOFvhRnIap2c bVqsl6Z+u+4zEGKqJh+bvMhk5k8dS9ZU1Ayi62puIo4t19CmxpVtw6GBCbM1j2VvrZtV RKew== X-Forwarded-Encrypted: i=1; AJvYcCVw51F034bBFJpVdK3EvFx++J86SNPFS+jmZGThjZ+a8PntPIighMYAVwQjwlhaL4pGQtyLE7V9+zGIhfc=@gnu.org, AJvYcCXBYq0ZI2ZHIgltWJm8NXJBMeZhQRaLMw2NYafQAZO8IPpN5dHDWhMGRBU8j7+v06ssXhLmgbHaHQ==@gnu.org X-Gm-Message-State: AOJu0YxGlPXBUPifBY0PNXr4AFcKyod8SS1Dpz9Gq8gcCExQKsstXSGO uyI6yLFx4aRJrhsA0RBIhE5cYAml28RwOvlH5Q4CW9yJQoBHPP5WgRKAczaC X-Gm-Gg: ASbGncvWVMVXmooZM1zOvNdvnMPN78UrD++XEZLkx5HlFg+zJARmWViDChIfdU3ZzfD a4uBodwR+FxCDFqzeGKH2Y/TnlBwXg9Kdv6Y/YCfP9UD0KwgYSJ1CdlQiU6QhQ6V6cmxpIP/ejD WV/YCukhp023gX5SycflKGXheO7nXFJ1aOSvLZG0oIdujsnr0wD/wJDHbk/P4d4YrDnrqBOV0Bf /42s0ZH6dNA9wuoHyPmuWPsNeRTE0MilZ5+a3kTbe3rJ7AWqBVbc2PsPovLHi7fWnpC8IQFjXyr LdBuzgLbrCdsB+++jxFVgrG06szn1BQ0RWvjWIRkrqO+g9KNegoaxUTC0wgyVj4/IQ== X-Google-Smtp-Source: AGHT+IFIPQAl1cW0y9k5GbJztjscjTTfaY9T+79Op9/7dnTurQm5aTeeMdACxmr7l8yd4E1Wtd9tZw== X-Received: by 2002:a05:6402:3206:b0:5d1:2377:5af3 with SMTP id 4fb4d7f45d1cf-5d81dd83b23mr46553026a12.5.1735138654019; Wed, 25 Dec 2024 06:57:34 -0800 (PST) Original-Received: from pro2 (p200300e0b73d6f00401d1c7c2fc22e2d.dip0.t-ipconnect.de. [2003:e0:b73d:6f00:401d:1c7c:2fc2:2e2d]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0efe4971sm818123066b.107.2024.12.25.06.57.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Dec 2024 06:57:33 -0800 (PST) In-Reply-To: <864j2r25hg.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 25 Dec 2024 16:37:47 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::629; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x629.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:327103 Archived-At: Eli Zaretskii writes: > So there are Lisp objects allocated by alloc_impl, roots allocated > via MPS, and data allocated by xmalloc that MPS doesn't know about, is > that correct? Correct. I'd perhaps change "roots allocated" to "roots declared". One simply tells MPS a range of memory [start, end] is a root of type so-and-so (ambiguous, exact). The memory itself can come from xmalloc for example. >> > Once again, I think this is very important for future maintenance. I >> > feel that this barrier thing in MPS introduces significant >> > complications into reasoning about safety of C-level changes. >> > Previously, we only had the mark bit to worry about if we wanted to >> > access Lisp objects during GC (see gc_asize, for example), but now we >> > have a much larger problem, AFAIU. How do we manage that for the next >> > 40 years? >> >> These problems do not exist. The barriers are transparent for the >> application, except in vary special circumstances, namely this shit >> signal handler. > > But I _am_ talking about this "shit signal handler". I'm trying to > understand how would I go about reasoning whether accessing specpdl > from the signal handler is okay. Is that because I'm supposed to know > that the specpdl stack is a root? If so, I'd need to figure out that > for every datum the handler accesses, no? That's right, but perhaps it helps that anything that can end up being Lisp_Object is not a root. And only those can be affected by barriers. > I guess I'm yearning for some commentary in igc.c, not unlike what you > wrote in xdisp.c at the time, which would explain the basics, like > what are roots, what's the purpose of all those root_create_SOMETHING > functions, what's the difference between exact and ambiguous roots, > etc. Because currently we are not too spoiled by comments in igc.c. Would a reference to the MPS Guide https://memory-pool-system.readthedocs.io/en/latest/guide/index.html# help?