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 12:27:45 +0200 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="38471"; 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 12:28:46 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 1s1kj8-0009kq-0t for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Apr 2024 12:28:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1kiI-0003Pf-N9; Tue, 30 Apr 2024 06:27:54 -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 1s1kiH-0003PJ-2U for emacs-devel@gnu.org; Tue, 30 Apr 2024 06:27:53 -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 1s1kiF-0005Es-96; Tue, 30 Apr 2024 06:27:52 -0400 Original-Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a58fc650f8fso257623066b.1; Tue, 30 Apr 2024 03:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714472867; x=1715077667; 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=ApHA1590fe4OJ+JOzR7A6tQ7t6PzP+bblR4hQjrhOjg=; b=CvWc45e7WUp3yptSEadW2FTmj7E7L1PMhpjjOt+pPOv2qPAoxHaLEhe9kf8nqz3bc4 bIbf6yaenUeUZARaoR9r0tdIK6xsOC1v1XwUdihr6+HuZ2C1/QurHzqWz+DRFf1oaMAM FnGjkB+7XoZ0esnBiUOkb73My5aB79lANErUQv+gVuMvu2FSGx0oaxbR5LwQsTRkwKNz OErKDFM+A+hFLInvUewX6QfxzFHzEPhOr3BZ3VzpVMUzz+I+ys8ZZXKOhJlQQu5hIij0 xMsiSTIZmM6/VRtLutAVk9hsrH1sP9OWkVWfk3Ck+LSzuDocuDnAM8pjlOX0ItYmWenS MrjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714472867; x=1715077667; 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=ApHA1590fe4OJ+JOzR7A6tQ7t6PzP+bblR4hQjrhOjg=; b=IskEyFjob7Zwi7Kbt27Lg4KFK/aHG5Ohe/2YpqduWd2KpeaWsTwPa02x7KprrJNpD+ i5M1mGvE/Z1I44zXEmaPvG6a16kys10YnNNDVT9GajHxg5oxf/fBzswUTFOASvgnMsZA BomBSgr+fXXcKlaw3ggHj0DRBkPjl6HhrOz3gN54JhtMIJqFGajgugL9V4I9SwJ1nz+C eLnbLRPkQkUYiEwYOAPH3xZnh5aBmb6AIImhYd0FKUfT6T+FPQcZlSd/HAQYdQ/UnODb /2YYv+4Y2ttTBIo/7B4SB34X4Ku2sjCvxY4yq1Jwx9H8fCVe6Yxdj9Fq0D5AE/l59HBh 7wsw== X-Forwarded-Encrypted: i=1; AJvYcCWbJqDws2EGs7NQ98NaEdNhEfjSLvnMcc1fCzaItRZU7hyVBvsWifZPadP7aXVDjxRPTqL2IBRVeXHSy7E5IPz42ety X-Gm-Message-State: AOJu0Yyr1nPOOpbyw0GKAzb/XgSk40rTvriXWIPqF5ijZC1U+sL67MMz Tq/wo7lSlpnGYOufDSH33I9NE0wWJtclKgbq240H7XsxJ4kgJwgq+T2KYg== X-Google-Smtp-Source: AGHT+IFxJPcttInkSJCyZ6To/4Gmop0ct1vXeR5TWyJLpk3Hy5J/74cBFoLy2TD3wLYuowEdGXY9sQ== X-Received: by 2002:a17:906:b210:b0:a55:387b:eef9 with SMTP id p16-20020a170906b21000b00a55387beef9mr9038008ejz.10.1714472866830; Tue, 30 Apr 2024 03:27:46 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3ae18.dip0.t-ipconnect.de. [79.227.174.24]) by smtp.gmail.com with ESMTPSA id z2-20020a1709063ac200b00a4e1a9e1ab4sm14864716ejd.157.2024.04.30.03.27.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Apr 2024 03:27:46 -0700 (PDT) In-Reply-To: (Andrea Corallo's message of "Tue, 30 Apr 2024 05:40:41 -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:318411 Archived-At: Andrea Corallo writes: > 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?=20=20 Yes. > 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? The exact algorith MPS implements I don't know either. The docs include some design documents, but I haven't read them all, and some I didn't understgand because there was some context missing. A number of possible algorithms that could be used are described in the literature, or one could glance at existing GCs for V8, for example. Hard to read though, for me at least. > 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). Yes, I think the same. It's just like some C code running. >> 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. Sure. For me personally the most important aspect is interactive user experience. Let's say complaints about GC pauses are not entirelly unheard of ;-). I even have one myself: In an Org file, with my init.el, GC kicks in every 5 lines with C-n/C-p (something font/jit-locking produces heaps of garbage). It's unbearable, and that's on my old battlehorse MBPro with i7 from 2013 which I used for years for C++ development in Linux VMs just fine :-/. > 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). MPS is also generational, i.e. objects eventually move to older generations which are less frequently collected. Haven't played with that knob though. Atm, there are 2 generations. If the CUs are in the loaded pdump, they won't be collected anyway, of course. How that works best I have still to figure out, but I didn't get a chance yet :-). And the pdump is also an aspect all in in itself... And in general, lots of things could be tried...