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: Fri, 03 May 2024 16:19:42 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40217"; 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 Fri May 03 16:20:34 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 1s2tm6-000ADM-0K for ged-emacs-devel@m.gmane-mx.org; Fri, 03 May 2024 16:20:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2tlO-0003sC-CN; Fri, 03 May 2024 10:19:50 -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 1s2tlM-0003s1-Kt for emacs-devel@gnu.org; Fri, 03 May 2024 10:19:48 -0400 Original-Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s2tlL-0005Bw-2Q; Fri, 03 May 2024 10:19:48 -0400 Original-Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a5872b74c44so1204818266b.3; Fri, 03 May 2024 07:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714745984; x=1715350784; 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=ZrPTVBNh/YfexAU/gL6ddvln9n1oGdIqwOLUl+Ycgio=; b=IHF2ZmMUFbBoiy01jAL+yak/b55hMrSpGBA7UXtHTJJtCSIqiohZGk4afayRq+B/dY G+x7wIU7e93dcpfxhAe2iL5EKARMn9RystyURSjOD0hkqdf7T12bT+GajQyvsbFEoL5l JtKh+46Kfy26YtWOIWZGOrO93xP9TPuENAFKsipO9SYZYHQiivZzPOF5U/kUUHgXZD4C NrJSthH9m4CPEFsT1xx0j4ILvqDN3T75a9yJcVqtf/sy8mZ24FjpmtAfCNU5lkBxq+9l GliDrRJUUjaNlCOtjiHt+RPZftYvoKR4b/zhEF+53gog0KiEtLAj63W5ZN0kG6yuqhnK DaaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714745984; x=1715350784; 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=ZrPTVBNh/YfexAU/gL6ddvln9n1oGdIqwOLUl+Ycgio=; b=gsHFLN1lNQi1uhr2LINAdQMoHNaS5OhxP0cDnI3tgH/MUWL7F6Z9F0bqzqR9dcl12R EzPGHVhRJ3IqUkxcu1DBsfqUNdZJNXIUKeTVxRZJP1N5fVkKwCYv4nNIAWlcO0QW2jdS EhKt0rhVlLnBqzdxgga220aXpufkfx2rHoGYbgQ6emr1htLxeb4u4oFhSYXwc8acDpfd vRdBdkdnp/qoGvSG0UHT/+nxvrhbOe0x4Qd6C9FigUyiwlIT2dDeOWe6iYmjwyRBytDR 9RkO3mCYGjkHKGfq0chM/6Oi3LdoIuA7ox+oipwED4NLSWlUrV4jdY13HiY8Q6Q3RH+e DCtg== X-Forwarded-Encrypted: i=1; AJvYcCV/zTxhHHt+OLEtjUNEYGwOUa71Umr4saz/zo1qBIgQ69OXHwWU2eUl33eBDwQdpaAURe1EY3uEuEIo9NWsUYJKlSIH X-Gm-Message-State: AOJu0YzZodeWQrPcFd+Kd1+L3EogGnMSh07M7k0MNePnVUr0J/dyBLvL p6C7/l7m4EPQ473RwA3Xua7dCiGA5ms9Rx00sHKHXyY41Z/hnxuNWCGung== X-Google-Smtp-Source: AGHT+IFahQuEqsPXiPFCp8mpfhzZnjv78RBY7GcDoPOuKMMHa6Rv+9bELtiHLjYdljmMAt8vnSa/dQ== X-Received: by 2002:a17:906:3e19:b0:a58:ff45:415f with SMTP id k25-20020a1709063e1900b00a58ff45415fmr1569755eji.44.1714745984018; Fri, 03 May 2024 07:19:44 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36a94.dip0.t-ipconnect.de. [217.227.106.148]) by smtp.gmail.com with ESMTPSA id jl24-20020a17090775d800b00a599acaff03sm404007ejc.19.2024.05.03.07.19.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 May 2024 07:19:43 -0700 (PDT) In-Reply-To: (Andrea Corallo's message of "Fri, 03 May 2024 09:35:34 -0400") Received-SPF: pass client-ip=2a00:1450:4864:20::62a; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62a.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:318689 Archived-At: Andrea Corallo writes: > You said: > >> The problem is not liveness, it's the existence of untraced references >> there. > > So my question is, there's really no way to express to MPS the > 'existence' of an object without impacting his 'liveness'? > > This case is supported by alloc.c as the change in discussion > demonstrates. Hm, let me try. I don't know what exactly you are asking, but maybe explaining it in different way helps. So, ... We have two things at hand 1. liveness 2. references Liveness with MPS and old GC is handled the same way. We have something on the stack, as an example, and that fact keeps it alive. No problem. References are different in MPS and old GC. In the old GC, _all_ references to live objects are _always_ correct because objects never move in memory. With MPS this is not the case. Unless we do something, only references that are _traced_ (updated) are guranteed to be correct, if an object ever moves. Or, alternatively we prevent an object from moving. I think the following C is similar to what we have in our case: Lisp_Object global; void foo () { Lisp_Object v = Fread (....); global = AREF (v, 0); do_something (); // MPS kicks in when we rea here do_something_else (global); } We read new a vector v from some string. This keeos the vector and its contents alive because it is on the stack. But, please note that only v is on the stack. The contents are _not_ on the stack. Means, in the MPS case, that only v cannot move in memory. Its contents _can_ move. In the C code above, when we reach do_something_else, this means that the reference in global may be invalid because v->contents[0] has meanwhile moved. Is that of help?