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 14:46:44 +0100 Message-ID: References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <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> 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="24972"; 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 14:48:12 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 1tQRkB-0006OY-7o for ged-emacs-devel@m.gmane-mx.org; Wed, 25 Dec 2024 14:48:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tQRiy-0001RH-Ef; Wed, 25 Dec 2024 08:46:56 -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 1tQRiv-0001Qp-67 for emacs-devel@gnu.org; Wed, 25 Dec 2024 08:46:54 -0500 Original-Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tQRis-0003mX-GG; Wed, 25 Dec 2024 08:46:52 -0500 Original-Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-aa69107179cso974181066b.0; Wed, 25 Dec 2024 05:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735134408; x=1735739208; 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=zwjJbCyBW4tb7BabhbX4o96WeLVAsEIVGuUt41bLT6w=; b=An1F7MkV99IENQb8SnDb4V6LSj9XACBj3wzSjcIYI1yJjEi5ri9vds8NMcVIZuLe99 XTNBduZVo8HfJUXKVOqu4iCxXTVlk08QgDO8Oar/aYYt+Zb2UFq+k2tsMM8IHEUR3XEc uN8hWWRQd0YVm2X4comII6G4gFDH/GCIfIM0ZtCBPqLxdVDHto68kAHzkKDXOuFYOCb/ Ynr5xxCS/Rozh8k0CMasPRpynNVG0ScWrJWY5jUvUMC+NMYMVXVHxHjf3wSWXfPgJ3hR mntuBiNn+4VhoeDrL3ggv5QSCMdlafEpxTrJE9Xyv/cU/Y13l/OLpNXxn1gJzNcSdO36 QvWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735134408; x=1735739208; 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=zwjJbCyBW4tb7BabhbX4o96WeLVAsEIVGuUt41bLT6w=; b=mfr3od0nY8XWrEAwSDAZaWs0714cg2Mh5Dtx0JtURz47MT99j0fiK0qrveL9kyO+tH MyV6E7wNiFicqqyz1lueobIlWR1g5mnBUU+q08xDnFbHHNCIs/rTleLFMx+eUwAN5dBn CoNWnIbNdX7NDqF1LdAI/O+lbe6ARXd4aRpzKS0hE8zwK5p5uvNQ1VSdSABpL4GruGJN q1fWyD4rccK39PM+BGDN8t2mdoFTyrLJqwnc3JjqVd9esQ3UMob+oo00Ul5fIwiNnLt/ ZEQP35TvSGZxNPbTtPPYl3TDkeoluMYAryz2upnOv+kM+g6zJdgDo5Y5wsZJFl+2/im7 8dPw== X-Forwarded-Encrypted: i=1; AJvYcCUVtloB3z0kbyRAm+B9+yLLkn5KM8iZRqq89qa3Yh1pwpLRX20TMkBQqXC/VYwFdPC7Rqpc4+shv91I98k=@gnu.org, AJvYcCVYyO3fi8TQw0JvEvHz0qWAzGQFsEh/Tu+APXD4LH+xMVbgcReJ/xWzDzrQ5hx4Gsl73xR4DtrghA==@gnu.org X-Gm-Message-State: AOJu0Yw4BPDmuS1i2PU6k2fFdytptQjr0eDHcwKsstvmg7EfY+zH9mC+ B3hXXootaGtihjeP5UKa5YjQJbYtUK13pgLa6PG/XjPs3faBUykumWnyfeDh X-Gm-Gg: ASbGncsErAZcZ5xj3UU6u3xakCF5AajxRZBm8QqRhOcaOYwKY0DUBjR8xupRS3anzoU PqmqQkBy1R5n7z1LXPclLuBoIU41msM+McAAaaNnEXpr6Ybay6gCaF+DGJ/uz7Co4XXzVGEs5aE fmULWRKWeMWna3WPkIDOaHz6oYWN5QdIcKMgtiUwXlAKLLYKQo9RPmx7TxLX5b5ovMvZmRdARRv MkFNBZ2t69FthWFNKmor+N+NDQMfyNjjLLppkQNQZyhdyQXG6+BGz17YNNjo58XYGD1nBuxvCOw +N9uVvuuQQhZWUFrgo+ErZ7Hb4l5ltg2BraJaR22MTgesPMxuDLqtD/oM90BF5IbZA== X-Google-Smtp-Source: AGHT+IG4XIDfJe9ExaE9FWljmX7TfN++4myrZ7lrlejXkvu7vdWAtDpcmqPYgFdHXP1lIHXATd9aNg== X-Received: by 2002:a17:907:c20d:b0:aae:8490:9429 with SMTP id a640c23a62f3a-aae84909672mr1304670366b.34.1735134407750; Wed, 25 Dec 2024 05:46:47 -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-aac0e89641asm795075666b.55.2024.12.25.05.46.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Dec 2024 05:46:46 -0800 (PST) In-Reply-To: <868qs329kj.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 25 Dec 2024 15:09:32 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::635; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x635.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:327091 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, >> eller.helmut@gmail.com, acorallo@gnu.org >> Date: Wed, 25 Dec 2024 13:50:37 +0100 >>=20 >> > . how is accessing F different from accessing the specpdl stack? >>=20 >> F's memory is allocated from an MPS pool via alloc_impl in igc.c. Most >> objects are allocated from a pool that uses barriers (I think except >> PVEC_THREAD). The specpdl stacks are mallocs (see >> grow_specpdl_allocation), and uses as a roots. There are currently no >> barriers on roots. > > So you are saying that the answer to this: > >> > The first question is more important, from where I stand. Looking >> > forward beyond the point where we land igc on master, I wonder how >> > will be able to tell, for a random non-trivial change on the C level, >> > whether what it does can cause trouble with MPS? That is, how can a >> > mere mortal determine whether a given data structure in igc Emacs can >> > or cannot be safely touched when MPS happens to do its thing, whether >> > synchronously or asynchronously? We must have some reasonably >> > practical way of telling this, or else we will be breaking Emacs high >> > and low. > > is that we need to trace each datum to see whether it is "used as > roots" (what does that mean in practice, btw?) or is "allocated via > alloc_impl in igc.c"? Does the latter include all the Lisp objects > (except fixnums)? Do we allocate non-Lisp data via alloc_impl, and if > so, which data? No, I'm not saying anything like that. Apparently I've used some hints/terms that you are not familiar with. Sorry for that. Roots: There are GC roots in the old GC. Specpdl stacks are roots, DEFVARs, control stacks, DEFSYM symbols, the bytecode stacks and so on. They are marked first at the beginning of GC. The roots and everything recursively reachable from them are all live objects. Roots in igc are basically the same thing. There are MPS function with which one can define roots, if you mean that by "what it means in practice". These MPS functions are called in igc.c. Please don't ask which functions :-). alloc_impl: This function is used for the allocation of all Lisp objects, vectors, strings, frames, everything that can end up being references as Lisp_Object. So everything except fixnums. And it is not used to allocate other stuff, the xmalloc family of functions is used for that. WRT to the mere mortal and so on: I was talking specifically about get_backtrace, and why it can be used as-is, in the way I described, to get a backtrace in the SIGPROF handler. What's the problem with that? I think what you write is a grossly exaggerating the situation with "trace each datum" and a bit implying "all the time" (re your paragraph below). Does that help? > > 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.