From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: MPS GC and its implications Date: Wed, 01 May 2024 15:43:08 +0200 Message-ID: <87frv1hclv.fsf@gmail.com> References: <87bk5tc1j6.fsf@gmail.com> <877cghc0yy.fsf@gmail.com> <86jzkhu5rv.fsf@gnu.org> <87ttjlabic.fsf@gmail.com> <87v8408wsr.fsf@gmail.com> <87o79sasl5.fsf@gmail.com> <87plu72y8h.fsf@gmail.com> <877cgfwe5g.fsf_-_@gmail.com> <871q6mptkj.fsf@gmail.com> <86wmodofvw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2015"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 01 15:43:40 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 1s2AFI-0000MU-5p for ged-emacs-devel@m.gmane-mx.org; Wed, 01 May 2024 15:43:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2AEz-00011h-MU; Wed, 01 May 2024 09:43:21 -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 1s2AEy-00011V-Mb for emacs-devel@gnu.org; Wed, 01 May 2024 09:43:20 -0400 Original-Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s2AEp-0000Xr-MM; Wed, 01 May 2024 09:43:13 -0400 Original-Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a58772187d8so811991966b.3; Wed, 01 May 2024 06:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714570989; x=1715175789; darn=gnu.org; h=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=F4vMPUb33aHytENPyXstbfkGM3k9nZaOPGEzEFR8vp4=; b=jzzbaft/VsNnmggUDZzoLCmY/2jWaYfyvg8ZqR3XeDtqeqwpcSD7szPa2Dbk5LBPUb zScpAu5Q8tCxiP6ve116a/MHUrtf3sD5WXi6HJXRlCL8iGHplpz7rvJCef4OMMOoKHj5 ElaTTQaEUlDDnh1RM8wUg/yOrkxr8xk1/cQnbWxeZvttP6wlI2W7mv8cv9rSguCeP5g7 AXac2LBMTRMZDUEClny8XrUk9DMzjPrsrjVAyg255ML0/Ju+WuAuewwShIdATCIIprHn tpyqr2lV4rxvjZAoXU6tPoe0CGjloPtQ7rwtikXDj1cDOtdc/R2A8Bm68uRI23748mHn nXJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714570989; x=1715175789; h=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=F4vMPUb33aHytENPyXstbfkGM3k9nZaOPGEzEFR8vp4=; b=LR5o0Ak8ZxbUm9n17GJQfaS4O1omXaisPDT6fTQE93drwcyG5dxX/YNAsNwvITYlkr uE/SoRUXNeQEzPP5pkQdbWfx+/Gnx0EEO2eCGnaG3mFyQxsP31ONl4kd2JQpkDbFjJz7 j8SVxILAbXAXrlmvwlEosLH/L7UG3ie+lEM+goydtBYixsKfuCCVyzxTodAUav1cHp0z hjj90E0Dtr9Mhmg3Ke05rXq0usbTsMQjL9GN4E4+A35UskZU1SEv2meNkc86+tj4Xh6c c20H9vd0BwKhAs9th0I/DPNzgi+VAyWRrcElGNQqgen7sPM78WQEL+Gj66N7cigxHTkG crRQ== X-Forwarded-Encrypted: i=1; AJvYcCUMnp9UrnEEREiVwlskjxG/JQpEbXiG8PSNxjT9MxP/ZgtyTBJSD5JOsUvP/bCjr2mgbf/ZI2NOhRT15kinGiCifVg4 X-Gm-Message-State: AOJu0YyixixCELrdq7nzTtFC57u5esFzvJOHETDlVsN7BjtRaqhAHLYX ySYegMDoqN7bRF/+og8/5p5uzKqqi6JhtBkRx7H5lT3h4MXcvoEPCjtvpA== X-Google-Smtp-Source: AGHT+IEA1akY/ZZwYtEGtJNiY3ZXjxTijV4bjmd+FprCM95QghoJ4pwy6Yn/8nIcypZqGr2KStGv9w== X-Received: by 2002:a17:906:e219:b0:a55:b039:58f6 with SMTP id gf25-20020a170906e21900b00a55b03958f6mr2459363ejb.17.1714570989282; Wed, 01 May 2024 06:43:09 -0700 (PDT) Original-Received: from caladan (dial-184253.pool.broadband44.net. [212.46.184.253]) by smtp.gmail.com with ESMTPSA id kt17-20020a170906aad100b00a58ae8464d2sm7641828ejb.211.2024.05.01.06.43.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 May 2024 06:43:08 -0700 (PDT) In-Reply-To: <86wmodofvw.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 May 2024 15:50:27 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::62e; envelope-from=eller.helmut@gmail.com; helo=mail-ej1-x62e.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:318475 Archived-At: >> I'm not sure what is with the buffer case, but the string case means >> that source can point to string data, which is in our MPS leaf_pool. I >> think we cvould use an exact scan function for that purpose, analogous >> to scan_specpdl. WSYT? > > If this is indeed needed, we are in trouble. When we take a C pointer > to buffer or string text and use it in the following code, it's > because there's a hidden assumption that GC cannot happen during the > time the C pointer is being used. If this assumption is not true with > MPS, nothing in Emacs will work reliably. > > Is this indeed a problem? Didn't Gerd just explain to Andrea that > every object referenced from the stack or even from a register will be > automatically "fixed" if GC happens and decides to move the objects? > If so, why doesn't that solve the problem here? The stack and registers are ambiguous roots. The objects they point to are "pinned" i.e. not allowed to move. So as long as we keep a pointer in a local variable, things should work out fine. For references in global variables, we can decide to make them exact or ambiguous. If we make them exact, we have to be very careful. > More generally, what happens with text of Emacs buffers and strings > when GC runs? I know what the old GC did, but what does the new GC > do? If we only have exact references to those, then they can be moved. > A related question, no less important, is: when can MPS GC happen, and > whether there's any reasonable way of being sure that it cannot > possibly happen while certain code fragments run? Would be nice to handle one catastrophe at the time :-) > For example, the > old GC could only be triggered by a call to funcall or eval (and a > small number of similar APIs); as long as the C code didn't cause any > of these calls, we could assume GC will not happen, and so any C > pointers to Lisp objects were safe to use. What is the equivalent of > that with MPS? Since MPS is a moving GC, this becomes much more > important; with old GC we only had 2 object types that could move > during GC: string data and buffer text. Now every Lisp object is in > danger of being moved by GC, AFAIU. > > Am I missing something? I think MPS is a concurrent GC, it means it runs "all the time". The reason why his works are the memory barriers. But maybe Gerd knows how things actually work. Helmut