From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Sat, 28 Jan 2023 19:54:49 +0200 Message-ID: <83357ua6ja.fsf@gnu.org> References: <837cx8cey0.fsf@gnu.org> <83357vauh5.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24213"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 28 18:55:45 2023 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 1pLpQX-00065A-66 for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Jan 2023 18:55:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLpPw-0002yl-Ps; Sat, 28 Jan 2023 12:55:08 -0500 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 1pLpPs-0002ya-Hf for emacs-devel@gnu.org; Sat, 28 Jan 2023 12:55:04 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLpPq-00048t-Jl; Sat, 28 Jan 2023 12:55:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wK6t2kqkMtVXaLiFCJSDAI7JUidwOHUBZMxbiCmmvec=; b=IpYINHhgsKC1 S4T8R4E1oGrffbPFDTHXAqyV7WpXfXMvK7CcMSiH1ZYV40ypTwzlSYSsjfEKJvleUOP8sOunU5c8l 3gbN4dYbWGhfPQwdnIul4+ALlTC2Z1Xp20cd5EU2uMhFht7+2FULqm4a4N9uZVlhPjnkzZHIzEIzg AC1aAWwJEcBrjOwCM0RFiu38ZQ3WwsdNvqW3L4DxnAWFghWAtQjA60hVH4okZK4zLBtZmd3sm5ecz 5SMyPp0giJSyCf3NfwCqy3nu70bItz2E7Dxp+/pF6z3OkrwEhIusECjijyECF5TVH5yc+/8tpV1Zp Tm6xTrzHns0WQ58Hj8sh6A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLpPp-0000xY-Bx; Sat, 28 Jan 2023 12:55:01 -0500 In-Reply-To: (message from Stefan Monnier on Sat, 28 Jan 2023 12:42:08 -0500) 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:302725 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org > Date: Sat, 28 Jan 2023 12:42:08 -0500 > > >> >> For trampolines, in the short term we should probably add a fallback to > >> >> use an eln-cache in the `temporary-file-directory` (i.e. use the code > >> >> we currently use when `inhibit-automatic-native-compilation` is non-nil). > >> > > >> > This have two problems: > >> > > >> > . it cleans up only on Posix platforms > >> > >> Yup. I hope it's "good enough" for our immediate needs, tho. > > > > Not from my POV, no. > > I assume using Emacs with a non-writable HOME/eln-cache directory is > quite rare, and if (in addition to the that) the > `temporary-file-directory` is always the same, then those trampoline > files that we fail to delete won't keep accumulating ad-infinitum. > So the problem is hopefully rare. People will use inhibit-automatic-native-compilation even if their problem is not non-writable HOME directory. So the fact that non-writable HOME is rare tells us nothing about the frequency of these situations. > And we do have a solution: pregenerate the trampolines. So you are saying that the "prevent writing trampolines" part of inhibit-automatic-native-compilation is not needed? > >> No: what I'm suggesting is to pregenerate the trampolines before we know > >> if we'll need them (a bit like `make trampolines`), but to place them > >> alongside the code that might need it, so there's no additional "small" > >> files containing nothing but a trampoline. Instead we add tiny chunks > >> of code (the trampolines) to other `.eln` files and we do it at a time > >> where we know we have GCC at hand. > > What do you mean by "alongside"? The code which needs trampolines is > > the code which advises primitives, and that is written in C. Where > > would "alongside" be in that case? > > We need trampolines because we call (from .eln files) some functions via > > (...) > > instead of looking at the function cell of a symbol, checking what kind > of Lisp_Object it holds, etc... > > When an advice is installed (i.e. when the function cell of the symbol > is modified), we need to update the `functionvar` so it points to > a trampoline which does the dance of "looking at the function cell of > a symbol, checking what kind of Lisp_Object it holds, etc...". > > So, we could pregenerate the trampoline and store it directly inside the > subr that's originally stored in the symbol's function cell. > So instead of (comp-subr-trampoline-install SUBR) having to generate the > trampoline, it would find it in one of the fields of the subr struct. Thanks, but I don't see how that answers my question. Unless by "inside the subr" you mean we should change the implementation of defsubr? If so, this is definitely not for Emacs 29, and we should discuss it separately. My question about what to do with trampolines was about Emacs 29.