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: Thu, 02 May 2024 06:24:07 -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="2488"; 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 Thu May 02 12:24:29 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 1s2Tc4-0000S4-Mt for ged-emacs-devel@m.gmane-mx.org; Thu, 02 May 2024 12:24:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2Tbo-00043u-PW; Thu, 02 May 2024 06:24:12 -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 1s2Tbk-00043J-RU for emacs-devel@gnu.org; Thu, 02 May 2024 06:24:09 -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 1s2Tbk-0005iv-II; Thu, 02 May 2024 06:24:08 -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=vUYJ4WkBj0FWpDUtVPcqSprXHC99m1llh6Og/W4LvMk=; b=TgN6lfTz2W4Tge067nnm Ymw4sGVCU6Pb2wWcMu8cx7Ck+zQmERRYOR029SSVP99D/cd/2gV5CnNu8KcxwmcEfewvqE3/yLWTp +LwpRorRlSh37oDPOXlnkkvqgyMIksdp3njYaO64TSMTs5ns9W4lNkToZNGjDyLhvYPrhvnr6sLn/ ko2q9FO7vhhkw5o4mQLo2Lh57glhZ1t0wkOjLkPzboMtwOcsYkHhU6MGRvTaWTKX8iq9w1luYFRyu jspPBZaioM+hU1oPbg9MHEQgYlo6sZF2zzwALO1slG/isQmP4eAigQvF1jdL2AJNK8c4VHUklF9aJ dADAaUI0qgG8fg==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1s2Tbk-0006qB-9N; Thu, 02 May 2024 06:24:08 -0400 In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Tue, 30 Apr 2024 19:35:44 +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:318560 Archived-At: Gerd M=C3=B6llmann writes: > Gerd M=C3=B6llmann writes: > >> Andrea Corallo writes: >> >>>> 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 on= ly >>>> 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. >> >> FYI: >> >> I have ambig roots for the relocs, as an experiment. That brings us >> further. Bootstrap.pdmp is built successfully, and some .elns are >> successfully built, too. It fails eventually in one file: >> >> ./lisp.h:1631: Emacs fatal error: assertion failed: STRINGP (a) >> gmake[1]: *** [Makefile:285: ../lisp/files.elc] Abort trap: 6 >> gmake: *** [Makefile:925: ../lisp/files.elc] Error 2 >> >> and it's super slow. The reasons for that I don't know, but I know for a >> fact that I didn't do anything for CUs in the loaded dump, which is >> probably not helpful. >> >> I think I let this ripe a bit. Maybe I find the reference in macroexp, >> and then don't need the roots. But I'll push it. > > Good news, to close the evening, letting it simmer without thinking much > helped again. It's indeed simple: There are references we don't trace, > as one would naively expect. > > - comp_unit > - ephemral relocs I think is not correct to add ephemral relocs to the compilation unit. They are not reachable by the GC from that path on purpose, so that after the load procedure they get GCed. If MPS is scanning the stack as our GC does it should just work. Are we sure this modification was necessary? Andrea