From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Some experience with the igc branch Date: Mon, 23 Dec 2024 23:20:34 +0000 Message-ID: <87msgmasx7.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <875xna6pnt.fsf@gmail.com> <87r05yax5a.fsf@protonmail.com> <87ttau5afi.fsf@gmail.com> Reply-To: Pip Cet 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="35084"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 24 04:22:04 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 1tPvUh-0008w0-8r for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Dec 2024 04:22:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPvTQ-0003rj-Nu; Mon, 23 Dec 2024 22:20: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 1tPrj8-0000CP-AH for emacs-devel@gnu.org; Mon, 23 Dec 2024 18:20:42 -0500 Original-Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPrj5-0005tm-Up for emacs-devel@gnu.org; Mon, 23 Dec 2024 18:20:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734996037; x=1735255237; bh=ZhCTWQbMXuyhORXgYSpH9+l0Xl6zU7AmO1c90ySHZng=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=IWWfIC8BAWnuhqnOSzlXvoPtaD4ptBkT68Va0GwjmlCJmO7gVERc/HAWmr4IOLaQW 77k++mRG6CKyldBR+ve+tfSQzK9+bUnY8uTPR2bUZefOnoZ/GiNR1UkCzIqYVy+FE/ LQph1i+YvCObU3ye2ZpE9eEbCPL3sqO9c5zOVUT+Ogl+gTf6+01n/08ehhqJ68ynf5 hNyKPj+Spbo+z235uZKF85RW3Qeo8XWjXK/WVU/aa8yWwmb6bpt1OF4bzApnXsd+e/ +rMmEo6fE6GlE6lspxUVpxHb0p3VXcucouCDkVe+59k6xQKMf0yfBz4NIBAgqp7uyX 4X5HbUBGZQL+w== In-Reply-To: <87ttau5afi.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0bca9c6d289ab1a83ddf1a21dc89ad05399764db Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.protonmail.ch 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, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 23 Dec 2024 22:20:43 -0500 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:326949 Archived-At: "Helmut Eller" writes: > On Mon, Dec 23 2024, Pip Cet wrote: > [...] >>> Also worth mentioning is that trace_hash uses XHASH, which is probably >>> problematic in combination with a moving GC. >> >> Good catch. s/XHASH/sxhash_eq/ there, I think? And let's poison XHASH >> when MPS is in use? > > sxhash_eq doesn't fly with headerless objects. Which objects would that be? Right now all IGC objects have headers, right? Did I miss any? > It should be obsoleted, IMO. I don't see why. Is this about cons cells exclusively? Because 3 words/cons is too much (possibly 4 words on W64 or 32-bit systems)? For vectors we can usually derive the length of the vector from the IGC header (which has plenty of extra bits), which would have the equivalent effect. Strings, symbols, floats shouldn't matter. That leaves conses. My guess so far was that you wanted to implement a hack where a headerless cons is a two-word object that would turn into a tagged pointer to another two-word object with a header as soon as its hash value is taken. That requires slowing down either XCAR or XCDR, I think, and that's sufficient reason for me not to do it, but I guess I misunderstood your plans. This would also mean sxhash_eq would allocate memory, so it couldn't be called from a signal handler without yet another workaround. (Note that cons cells used to store long lists are inherently inefficient: naively storing an n-element list with a header requires n+1 words, but even headerless cons cells will require 2*n words. So if we really decide we need to reduce cons memory usage, I'd look into that instead.) Pip