From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Sat, 4 Feb 2023 17:05:19 -0500 Message-ID: References: <837cx8cey0.fsf@gnu.org> <83357vauh5.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> <83357ua6ja.fsf@gnu.org> <83zga28ra8.fsf@gnu.org> <83r0vd97s0.fsf@gnu.org> <83lell73yv.fsf@gnu.org> <83k0145guk.fsf@gnu.org> <835ychtcq9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17656"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 04 23:06:23 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 1pOQfv-0004P7-6Q for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Feb 2023 23:06:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOQfD-0001Um-6l; Sat, 04 Feb 2023 17:05:39 -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 1pOQfB-0001UR-BC for emacs-devel@gnu.org; Sat, 04 Feb 2023 17:05:37 -0500 Original-Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pOQf9-0005Ao-As; Sat, 04 Feb 2023 17:05:36 -0500 Original-Received: by mail-pl1-x636.google.com with SMTP id h15so1291396plk.12; Sat, 04 Feb 2023 14:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kh+rjlj+JJMyKXlHnTJSJYKougPXW/oqJN4Hy/RrNjk=; b=BQng8iBY3w/cfFvexYuKOPPWIS2rue8fmjt9pnxeNBX8mZnuQcTObimJm5NpvejHrl K+QI5iyD56fbhuwnGa/kIWsBQZSnDirbiB94QfqKcqztyx5hwQ/d0B0Ng2a4XAia5a4L 7zYZYbJYm23n888PX3i1HK4Id8U3liZVEan7GQuGo+4t402FWcPYbbN83nWut75EQgoy 549kqiBUbZXsvTrv+Fyo8BA5JWGSv6BrgGEOwrrpzxrX9NISYQRxDdXvFstSGb6ujYNQ LEQ43GVCQILjSg0Dxa6rRStmuHr2T4nExjetV64OME9EN97WXVtXYegp+IITSNWqwjZy XpWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kh+rjlj+JJMyKXlHnTJSJYKougPXW/oqJN4Hy/RrNjk=; b=aWm8ckS2c12V89iSYKSpDTTs6hr/nFZOPNstPckqBTWKa7HQi7ylhiqa0LeOnOU6i0 zt0gvT64QKWQFuGmEtUrO2cKyuz4HUI03yvyp2IoMBxdPuU/n2m8AO7Bj6hyW8stxcPV YxaUWKWIkUyCy3M6EXihP1jSRng/wsvFio9CBNEu0zG4JS1mFMIkUXmVXJZquGcQ+YMy ZYviwcpd1Syu2aiexajZHczo4NnDQWH585/HyNoGQXULqnyif2r7u621+BtKPTaGRpVY Hdi3cikGitnWsFcUQDJ86FunEKgjglisQBsfrHwQMUdHEd01hHG4Pk3qy3ZEw1TMoL2H KhDQ== X-Gm-Message-State: AO0yUKVZISHBtsCgWnUo2f5t3fMsmQC2IhpD8uvC2z2ItW74gjQLtVgc NaIKxTvWwYSQy/zcfv3cgxl8igjPsOCmYFBz64946GU6 X-Google-Smtp-Source: AK7set/bm1UaMSxGy7Q1gbM+pWZhU6x2/wsdmg61P/qP2Y7fFJD7UwDqsRBkAvf5Hx6zSiBDE/DfBEvYBydPfSMrY3E= X-Received: by 2002:a17:90a:6b0b:b0:22c:2401:a6f6 with SMTP id v11-20020a17090a6b0b00b0022c2401a6f6mr2215573pjj.29.1675548331516; Sat, 04 Feb 2023 14:05:31 -0800 (PST) In-Reply-To: <835ychtcq9.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::636; envelope-from=owinebar@gmail.com; helo=mail-pl1-x636.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:302988 Archived-At: On Sat, Feb 4, 2023 at 3:08 PM Eli Zaretskii wrote: > > > From: Lynn Winebarger > > Date: Sat, 4 Feb 2023 14:55:27 -0500 > > Cc: Stefan Monnier , eliz@gnu.org, emacs-devel@gnu.org > > > > > The node Advising Named Functions in the Emacs Lisp Reference says: > > > [...] Especially, Emacs's own source files should not put > > > advice on functions in Emacs. (There are currently a few exceptions > > > to this convention, but we aim to correct them.) > > > > Are those exceptions considered bugs? > > Not necessarily. But this should be used rarely and only if there's > no better way. > > > Something in emacs is putting advice on call-interactively. When I > > extended the baseline dump to include essentially all libraries > > included with emacs with native-compilation, it caused an infinite > > (asynchronous) regress while compiling the trampoline for > > call-interactively. I wasn't aware of this until /tmp filled up. > > Is this with Emacs 28 or Emacs 29? This was with 28.1 modified to support dumping with many pre-loaded native-compiled files. I disposed of that experiment (at least, of all copies I had access to), which was created on my employer's systems. I'm working toward implementing the functionality for the dev branch, but my first step has been to create the infrastructure for testing my work on build.opensuse.org against different versions of libgccjit. As far as I know, emacs still doesn't support dumping arbitrary native-compiled libraries at compile-time. Which is too bad, because the dumped version is a LOT faster to startup. As per the other recent thread (3x increase in startup time), loading eln files seems to be considerably slower than loading elc files at startup, but in dumped images the difference is probably the other way around. I've since approximated that dump with a byte-compiled version and the user function dump-emacs-portable, but then I have to install before-init hooks to systematically replace occurences of the user name and home directory in variables and customizations to make the dump usable. It's a kludge no distro would want to use. Even then there are a handful of libraries that have to be kept out of the dump (using bogus "(provide )" expressions) and then explicitly loaded in an after-init hook after removing the bogus features. And they aren't consistent with the ones that were problems for native-compiled dumping. But my point is, loading that byte-compiled dump takes somewhat longer than loading the native-compiled dump that had twice as many pre-loaded libraries. Emacs needs a lot more work to really support compile-time dumping of a larger set of libraries. There are too many instances of code evaluated at load time that should be evaluated in a before-init or after-init hook, that depend on variables set in C code after the dump file is loaded. Or run-time services like dbus. To really support site-specific dumping, a robust analysis identifying that code and transforming it appropriately would have to be performed either prior to or as part of dump-mode. It's non-trivial. The changes to the C code to deal with additional objects like text properties while purifying are (or were) trivial by comparison. Lynn