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 GC and its implications Date: Fri, 03 May 2024 15:48:15 +0200 Message-ID: References: <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> <87frv1hclv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18618"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Helmut Eller , Eli Zaretskii , emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 03 15:49:08 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 1s2tHg-0004gT-El for ged-emacs-devel@m.gmane-mx.org; Fri, 03 May 2024 15:49:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2tHI-0007xG-CQ; Fri, 03 May 2024 09:48:45 -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 1s2tHA-0007wc-F7 for emacs-devel@gnu.org; Fri, 03 May 2024 09:48:36 -0400 Original-Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s2tGv-0008Pt-6m; Fri, 03 May 2024 09:48:36 -0400 Original-Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-51aa6a8e49aso11188448e87.3; Fri, 03 May 2024 06:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714744097; x=1715348897; 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=XwqHKbXw0ira/n7X9P6RQcazFcaLakd/60rTEKztxcU=; b=BC4sgb9vi49+bJBYVFjSECcr54o2gZTMdoN1X24MJM3RiRRIwFMKZDOi0fBaqrW7bI QXjsB4kBjhCjOHA6jh53ZEKiuF5t5s7+C5Qsh5XEbOUDCPO5cfP0+qpkkoM3g/dm7oYb hSUVPy6somCGgTWSYqvTgy2r9aNyP7byJpBULEAD/Q/h2bTKDktzB0en5VijIPULPErt h1Xwol25J3LjRGv/pYolXdPZbA7AB3cmsqxTyihsK7OXRnbife5OCq0OXcahsOZqoAL1 0TJOkkJ6GWtQ1eX9mOLYCQpfIUeUdagu7AxtztyEUk697SMruAvEgivZfUNOOwOMCwmN qrHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714744097; x=1715348897; 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=XwqHKbXw0ira/n7X9P6RQcazFcaLakd/60rTEKztxcU=; b=CcQKfhAnTJBvZwZSXDLaubLM89YBtcu3ahASvclghRo1MjO+HVjRJ/0Q03ctu/byHR MygXEmzb/cH4lBvqG+CODGPoHxVRwy1++pPqPWWFak0cCJaFZ4APCQB0kwGz1t4sgzWn DUum3r/jrjfQCh4l91cf877R7Wp91z8hEI4rjX0838j9+183hj1hPNr1ifVSCi+Zgy2t 8ez7gZ/MCOwFrRokkEVt2bmPLVOyqXTdk4lDnGAXPfosZTRY3kTErRElbDcxt8v2fCyA 4kDt0CTrZ6F7q5s75hCQGktJTI1jfbgywl9gc+Nuw/JaToD/IrvodY+qjrolLJBn/0WI LptQ== X-Forwarded-Encrypted: i=1; AJvYcCU37dpSh9EJJ0tdKwkA+LzRy7G61Xd+v4O5swNxAUPPT8VfwnRg7GOYd8RAjtyc1tEi7KTPR7tUth3GfNTEwE0xVwyj1JW1pCJdcFUKvGZLso8= X-Gm-Message-State: AOJu0YwQAosY6+N+xcx/WXw0pXYJUQY9k3bBEcxApx6sLNVj7sZwn6nu DXf9AtZnT0z81XoakzGoh0Dr76tJZmV5fU+mPnjN7xp+inFtdNxNsZdYjQ== X-Google-Smtp-Source: AGHT+IF8aFQ/DtzWnaxULqDHCE3re/ZTbsSaN2FOkwtR/HIaymVopRVm3+BOrWnxHCTcUjC/3Nr6ag== X-Received: by 2002:ac2:5473:0:b0:51d:97e8:d2ea with SMTP id e19-20020ac25473000000b0051d97e8d2eamr1981762lfn.30.1714744097114; Fri, 03 May 2024 06:48:17 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36a94.dip0.t-ipconnect.de. [217.227.106.148]) by smtp.gmail.com with ESMTPSA id cf27-20020a0564020b9b00b0057270606829sm1709230edb.85.2024.05.03.06.48.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 May 2024 06:48:16 -0700 (PDT) In-Reply-To: (Andrea Corallo's message of "Fri, 03 May 2024 09:40:48 -0400") Received-SPF: pass client-ip=2a00:1450:4864:20::129; envelope-from=gerd.moellmann@gmail.com; helo=mail-lf1-x129.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, 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:318686 Archived-At: Andrea Corallo writes: > I guess you are saying that moving does not happen in a parallel > fashion, and so we'll still stop the mutator? Right. In a resonse to Eli I came with this explanation attempt: Eli Zaretskii writes: >> I think you're overlooking that registers and stack are ambiguous roots. >> The presence of u.s.data in a register or on the stack _prevents_ it >> from moving. > > That doesn't resolve the difficulty, it just turns the table. Now we > could have a race condition between the Lisp thread loading a pointer > into a register or pushing it onto the C stack, and the MPS thread > taking a notice that the pointer is in a register or on the stack. If > the pointer was neither in a register nor on the stack when MPS > started GC, it could decide to move the object, while the Lisp thread > concurrently loads the pointer into a register. So we might think the > object pointed to is unmovable while it isn't. > > What am I missing now? Here barriers come into play. Let's say, for simplicity, that we are talking about an object on a VM page P. In its thread, MPS decides that it wants to do an increment of work on P, say it wants to move objects, without the chance that MPS and client threads interfere. So, MPS puts a read barrier on P (say with mprotect), so that other threads are interrupted by a signal when they read from P. MPS puts a write barrier on P so that the same happens when a thread tries to modifiy P. Does that help? Barriers are the reason why things are done in an orderly way.