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: MPS: native comp Date: Tue, 30 Apr 2024 11:18:23 +0200 Message-ID: References: <86le4wsj14.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="31865"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org, Helmut Eller To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 30 11:19:44 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 1s1jeJ-00084M-AP for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Apr 2024 11:19:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1jdT-0006u4-Jr; Tue, 30 Apr 2024 05:18:52 -0400 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 1s1jd7-0006rj-Uo for emacs-devel@gnu.org; Tue, 30 Apr 2024 05:18:36 -0400 Original-Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s1jd5-0001K6-Js; Tue, 30 Apr 2024 05:18:29 -0400 Original-Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a58eb9a42d9so371504166b.0; Tue, 30 Apr 2024 02:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714468705; x=1715073505; 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=hVUfGfKRmI1TxWm/Eqn+RNTC4TUwkBibhQ/JH6+5YYI=; b=X7TYzpb5HcSV74Un9aa9QiIPEfeZOTDVwXkIPl0gloF/14PkzRFKX8Fa5IfJENyBhQ p4c5FLLVppd1nvnvIE4Z9OYE1BZYd/S/qeIJgfWAQLlOQCL9n9coJQ/wU3lXfEFGTq46 RPO98pvNAlOEP5GaxZ6QfohqrDd60OWgu0/JRYbjANlFWUKK7U+clsBXxiJHNPh7+63X 4wXz7Wapw938Ohjvqrbr04+MF1nnGXJI6ZyAUEVXHaHbEAb+ht9rXgV+SCTsyE8PE4/y HR5tIcrMoXmxHd0avOr+svRSuzYS7QwA/teMj58Bsoar/Ja7I1yb7QNKfxt61ZzzX4sY fGHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714468705; x=1715073505; 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=hVUfGfKRmI1TxWm/Eqn+RNTC4TUwkBibhQ/JH6+5YYI=; b=gnMIhFCxOHceIkmPefl5j5f6ExIfXzr7SbqbRuABWoIO+4XRLrEG/EZK2ihjwnJ2d3 aaQxAK1W9RQ1HqBPTpJhEFdb3GRCMYcEJawCBAb4tsz88K4ixD2shT1h4s7UH2DIEXKp 7wKavhHzWwBwlhzzbWtnNsZVjjJ14Gxl9+5IfA/O0jyuVmiCwBkdkKn2AGkCkifT+F8Z /xmAQjRZHi7WBw65BEn0vrfEuaSAs9mMEv1XsYwHmq5OrXM9g7NqPWbWWGFIl8I97J2M Yr5dX/sOwaJA3hNZCjMn9WCmhD8vEI7hQ99p3CrbcnyLzLNMsWicfE0ou3QOYBI9qWQg iqMA== X-Forwarded-Encrypted: i=1; AJvYcCX8YU3xTwIsnIJYrzNJnSNT7H2RAhAkk8lAKqQ9XnoPpXAMssRgR9heZnEG4bd5ZLWcw6+Wftk9S3AckLYkl962BiWF X-Gm-Message-State: AOJu0Ywa8ZCv6A/JUPaOgRWivBivqq4QECJG575GSBwb0FJtCX/40hXq RbU1Rz38JiF0bNBi34qlGKRVq6UjLUpu0vsGgn4fHwfEZVo28IGat/Igyw== X-Google-Smtp-Source: AGHT+IEftYR/DYMPeEku1Qi2mYmD7nEQVBpg4Hc4pyi+YyB1i11sPHQPkTviRzGHjPDsWboBPMcxSA== X-Received: by 2002:a17:906:853:b0:a58:8fa6:df18 with SMTP id f19-20020a170906085300b00a588fa6df18mr1270789ejd.41.1714468705049; Tue, 30 Apr 2024 02:18:25 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3ae18.dip0.t-ipconnect.de. [79.227.174.24]) by smtp.gmail.com with ESMTPSA id f7-20020a170906c08700b00a51a80028e8sm14850776ejz.65.2024.04.30.02.18.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Apr 2024 02:18:24 -0700 (PDT) In-Reply-To: (Andrea Corallo's message of "Tue, 30 Apr 2024 04:54:47 -0400") Received-SPF: pass client-ip=2a00:1450:4864:20::62d; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62d.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:318409 Archived-At: Andrea Corallo writes: > If the object was moved and the d_reloc is now updated by MPS I've a > doubt: > > What if our object (say d_reloc[x]) is loaded in a register by the > compiler? How does the register gets updated by MPS? In native code we > do this all the time for performance reasons. MPS traces registers and control stacks as ambig roots, so a reference from there makes the corresponding object immovable. >> Next strategy or tactic, I think, could be to produce a C file for >> macroexp.eln, and see where the symbol appears. I would imagine that I >> can deduce from the text representaton of the constants in C what index >> correspondons to the symbol, and then see if it is used in surprising >> ways. Maybe. WDYT? > > You'll probably see what I mentioned above. At the beginning of the > compiled function we load in regular variables the lisp objects from > d_reloc so GCC leverage the register allocater and keep in registers. Yep, I see that. > For instance we do exactly this 'byte-compile-form-stack' and others > here: .... > /* byte-compile-form-stack */ > slot_3 =3D d_reloc[(long long)1]; Haha, I hadn't even remotely occurred to me that you would emit a comment with the name :-). That makes things a lot easier. =F0=9F=91=8D > I think the easiest is to to make objects loaded from native code non > movable. Is this possible with MPS? What would be the downside of this? > They are very rarely collected anyway. WDYT? I'd personally prefer to trace comp units in the usual way for Lisp objects, i.e. the fix_comp_unit. Main reason is simplicity. The tracing function is super simple, we only have to identify where in the comp unit data structure, or dylib, references exist that have to be traced. Registers/stack are not a problem (see above). Other reasons, not so important, but anyway, is reducing the number of roots. Every root adds to what MPS has to do. And ambig roots make objects immovable, which is somewhat against the spirit of a copying collector. Just my personal opinion, of course.