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: Some experience with the igc branch Date: Fri, 27 Dec 2024 18:37:50 +0200 Message-ID: <867c7lw081.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> <868qs329kj.fsf@gnu.org> <864j2r25hg.fsf@gnu.org> <861pxv234y.fsf@gnu.org> <86zfkjznat.fsf@gnu.org> <86ldw2zy6s.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="16963"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@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 Fri Dec 27 17:38:50 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 1tRDMP-0004DJ-Tw for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Dec 2024 17:38:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRDLa-00048e-Oa; Fri, 27 Dec 2024 11:37:58 -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 1tRDLY-00048A-SS for emacs-devel@gnu.org; Fri, 27 Dec 2024 11:37:56 -0500 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 1tRDLX-0001bG-3P; Fri, 27 Dec 2024 11:37:55 -0500 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=wXOlmL8RIOuQoNJjJjJPMEoRcFM68tuEjil3E8BqeTE=; b=NjQQPTTIQU8rZzztEaBT 0MIWvB2ffCfSOdR0FpMNK51YxShRDairBigC1bQDCIzTMXqtDj7N6fAXQQoDlHEQwIPKKN7GP3XDl /BNzBp9gVCyxeI6QzG6Qx8jTsJEia+bXTAeySHgzzJwD5yRtwgfEQVqoOzmy8QYlo7cEZNqSpzIBM 98V9ryyoJcg53UvDamzsN8sZ+uQNhXTTiFd1keOT1gDxnqhDOjO4yaBXQ5qZUPD+Co9XiHyNj5ZrN YuHfLjB2IK4Zw2ThZHZB3NHxyVxvKZXEsARkoE9DxtjRSDU8Wh75AYp+osjYGHOgQsf2aD5WGZXbt gn0QXtxo6QJ1YA==; In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Fri, 27 Dec 2024 14:56:06 +0100) 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:327218 Archived-At: > From: Gerd Möllmann > Cc: Eli Zaretskii , pipcet@protonmail.com, ofv@wanadoo.es, > emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org > Date: Fri, 27 Dec 2024 14:56:06 +0100 > > Gerd Möllmann writes: > > > I've reached the point where I don't know what else to explain. Could > > always be improved, of course, and so on. Please find attached, with > > request for feedback. > > Ahem, just remembered that I had already an admin/igc.org in the branch, > so I've now replaced that with what I've written. Thanks. Some questions about that file: In contrast, the new igc collector, using MPS, is - 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. When copying objects, a marker is left in the original object pointing 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 that 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"? AMC implements a "mostly-copying" collector, where "mostly" refers to the fact that it supports ambiguous references. Ambiguous references are those from ambiguous roots, where we can't tell if a reference is real or not. If we would copy such an object, we wouldn't be able to update their address in all references because we can't tell if the ambiguous reference is real or just some random integer, and changing it would have unforeseeable consequences. Ambiguously referenced objects are therefore never copied, and their address does not change. This should be important to understand why some roots are submitted to MPS as ambiguous -- because want to prevent them from moving, right? 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"? igc provides a number if functions for doing such allocations. For example 'igc_xzalloc_ambig', 'igc_xpalloc_exact' and so on. Freeing the memory must be done with 'igc_xfree'. An example of using these to reference Lisp objects in malloc'ed memory would be great. Stuff that I'd like added: . a few words about the root_create_* functions . same for create_*_ap functions . why do we need the finalize_* functions? . some explanation why pdumper needs special support from igc Thanks again for writing this.