From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: MPS: native comp Date: Tue, 30 Apr 2024 05:40:41 -0400 Message-ID: References: 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="35427"; 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: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 30 11:41:49 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 1s1jzh-00091Y-4i for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Apr 2024 11:41:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1jyv-0004DW-4Z; Tue, 30 Apr 2024 05:41:01 -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 1s1jyl-0004AN-FJ for emacs-devel@gnu.org; Tue, 30 Apr 2024 05:40:51 -0400 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 1s1jyk-0005nS-6o; Tue, 30 Apr 2024 05:40:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=G9ZaqRN+oh0yPzYxGWVeIzWdwe3clMZOPu15hDWxZbI=; b=eS97pQXVJ2HBA/+E6GLl 8U2EpqxHtlRSRFdXYxXNTdpvpX55loYdpXmNzolmhkGbMFctIndGgOg5HWdLD+ydPyTz4DAPc1ydn r9KVKSgbhAwlYy/0RGaoIRtEi8cBOTQhzFz7R+P5m4EbtCnL2+OJKg9JlFBJk1qJQDqaUjh5z6hXM DJCY8NV/yHDdAm+F48kTPEOo1fAW/HQDzncRKq/IOE6Zf3VpVQmKvvN99cURssIfIx+hCtqgBICJL rZg92mq6G98yIa0nW3XX5gaPdxYUmQbkmsgcYmYuqBVCd4GoMXBdPLOBhrk4xPQOhEb1ARUQXa+2c PXizWpk7/xnOTg==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1s1jyc-0006FS-Vk; Tue, 30 Apr 2024 05:40:46 -0400 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Tue, 30 Apr 2024 11:18:23 +0200") 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:318410 Archived-At: Gerd M=C3=B6llmann writes: > 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. I think I miss few bits to understand MPS: If stack and registers are scanned I guess MPS has to stop the mutator thread no? In the moment after the mutator restarts after the scan other ambig roots might appear, so how can such moving collection be done in a parallel fashion? Also if this mechanism (I don't fully understand ATM) is working the issue I mentioned of values being kept in registers should be a non issue. Code we generate from Lisp is not very different from the one we compile form C (we still have registers spill/fills etc). >>> 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 To survive I had to find my way somehow :) >> 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. Well other than spirit and possibly simplicity we should evaluate if (and in case how much) is the cost to have this objects movable vs non-movable. The starting point for me is that this is a very special kind of object class we know in advance is very rarely (if ever) collected, so would be a pity to not consider this in the definition of the GC strategy (assuming is an option). Thanks Andrea