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: staticpro everything Date: Wed, 01 May 2024 15:54:03 +0200 Message-ID: References: <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> <87o79qng1p.fsf@gmail.com> <86sez1oevk.fsf@gnu.org> 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="21480"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: eller.helmut@gmail.com, 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:54:58 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 1s2AQE-0005KX-LA for ged-emacs-devel@m.gmane-mx.org; Wed, 01 May 2024 15:54:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2APU-0005vk-G2; Wed, 01 May 2024 09:54: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 1s2APS-0005vW-H2 for emacs-devel@gnu.org; Wed, 01 May 2024 09:54:10 -0400 Original-Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s2APP-00043Q-Lk; Wed, 01 May 2024 09:54:10 -0400 Original-Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-41b79450f78so39312565e9.2; Wed, 01 May 2024 06:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714571645; x=1715176445; 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=JqQaPuoE1rrzXriTlXjwd/kk24i6IGFYXIh5oIJLYhI=; b=mVfQvD5jPqn8ByYkr0x8sXV+tfwFD3IHT9wdho1xhtugZOWPrycTsgdxlLxWACh6gP naH9oIG+yShsyItGDg3+TVnycrCqOlQvU0+LKrdrKT0qq0JOgqTMJKZCp75cyl53/obb GxFwj5EX+SSfD+7y5KrwT3dpVAZt3mJW8LkakCZenOlMztbbspGdKd2NbU7IMke3uXMN wQV5k9eaqq7FZgFpuDssRHBquLRN1jjRc70fWzHCvjrnf4DwtEv3BDpuis9DUQr4heeK Jul0dUq8S3kvUPeQ0EPrXNLPANn4MJZrxQuw2IO2uBPISJlPq3j53XNPQWugOaXN/EBs tMIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714571645; x=1715176445; 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=JqQaPuoE1rrzXriTlXjwd/kk24i6IGFYXIh5oIJLYhI=; b=OLk0Q7UfDJvOaecKE1lPan89p2ZbDqJXmu2HmW9JnrmXXjkCqhS5rY9oq+iFUwxeDz 3SVHoMc0B6VZ0+4H3h8WwwL/IWCax6r+cXplf76T5jxR0STeKYMp4lptNM6grmljAAlF HBKpq196142eVjnGkmevguG4e6pVDGkET/Y61kt+IRCNOyFQk6NsxB26Wv5OjkelCitp 7bcyaRsqiBdtoTraeyJRvpkJT6+MFG3NWgFaCFSyeMl468XQQr6n64k8FjWR7UgAb3oM ds82ZjI3ekMuB6MRHdlEfA71NWvxgNSbmXJ11tUi+1nl0TnnPq7U8jiVdmvXP0ibXCVE XmuQ== X-Forwarded-Encrypted: i=1; AJvYcCUe0es4s8td1glMSTMd8NUD3o7BqtqYCBMMSS5tQFy1MdPii9j0Po9OCh9RQ5/quBRPeiTOZvQR2RIzMOMXXUP8qRuy X-Gm-Message-State: AOJu0Yxrz3ws+EImjldOjRD8NfvQP2brFULEGM4BlA/DKl57GE50NlD+ S055GLQ09MpxDgB6q2hUxHYNeeLGsydxxBM/AWNei9SAlRsrUCl6KS5d5w== X-Google-Smtp-Source: AGHT+IFKeSR80ESNgezwU5Syp4OACYdDcK14qWTecX+ubTOgpUIRvNrNIF49M98H2Git/6dAfjDJyg== X-Received: by 2002:adf:db43:0:b0:34c:3d1d:edc2 with SMTP id f3-20020adfdb43000000b0034c3d1dedc2mr2486698wrj.58.1714571644985; Wed, 01 May 2024 06:54:04 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e362de.dip0.t-ipconnect.de. [217.227.98.222]) by smtp.gmail.com with ESMTPSA id b16-20020a5d4d90000000b0034c59c41f45sm13590181wru.7.2024.05.01.06.54.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 May 2024 06:54:04 -0700 (PDT) In-Reply-To: <86sez1oevk.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 May 2024 16:12:15 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::329; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x329.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:318477 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Eli Zaretskii , emacs-devel@gnu.org >> Date: Wed, 01 May 2024 09:46:25 +0200 >>=20 >> Helmut Eller writes: >>=20 >> >> 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? >> > >> > Yes, I think would work. >>=20 >> With an additional complication: the string is in MPS, of course, and to >> get to its u.s.data pointer we would need to access it, say to compute a >> new source pointer in case the string has moved. I'm not sure such an >> access is allowed in a root scan function, because of barriers :-/. > > Can a string move while coding.c uses a pointer to it? With the old > GC, it couldn't, or else we couldn't be using the pointer to its data. > coding_set_source is basically a small utility function, almost a > macro, that is called at the beginning of en/decoding processing, and > the stuff it sets up is used during that processing; it never leaks > outside of the caller of coding_set_source. So I wonder whether we > indeed need to do something about this (and similarly about the buffer > text branch there), or maybe we see a problem where there is none? > > I already asked more serious question related to this, so I won't > repeat them here. Would you agree to delay these questions after reading my other mail? I hope that mail answers the underlying question, so that this one might become redundant. >> Maybe one could replace char *source with an index? Or passing the src >> around instead of the char*? I don't know how it is used, though. > > That way lies madness: we will have to basically abandon any C-level > access via pointers to members of struct's that back Lisp objects. > E.g., we have gobs of functions that access windows via pointers to > 'struct window'. > >> > But I just realized that now that about any char* needs to be looked >> > upon very carefully to decide if it could point to the leaf_pool. >> > That's a problem. Maybe a show-stopper kind-of problem. >>=20 >> Could be. I wonder how to find out how many of these cases there are. > > They are all over the place, IIUC. Scary. It's not bad. See the other mail. (And with the clang Python API one can do really interesting things, I see. If only the docs weren't so terrible ;-))