From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.bugs Subject: bug#36447: 27.0.50; New "Unknown keyword" errors Date: Tue, 9 Jul 2019 20:01:14 -0700 Message-ID: <7c22ff8d30102b8e4c2d2a766c0cf60b.squirrel@dancol.org> References: <875zon7x0a.fsf@web.de> <87lfxdgs1k.fsf@web.de> <83y31capj1.fsf@gnu.org> <83tvc0anwi.fsf@gnu.org> <83r274an61.fsf@gnu.org> <83pnmoacft.fsf@gnu.org> <8736jjgovp.fsf@web.de> <87muho2mfn.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="151311"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Michael Heerdegen , Lars Ingebrigtsen , 36447@debbugs.gnu.org, Stefan Monnier , Noam Postavsky To: "Pip Cet" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 10 05:02:28 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hl2sD-000dDs-4L for geb-bug-gnu-emacs@m.gmane.org; Wed, 10 Jul 2019 05:02:26 +0200 Original-Received: from localhost ([::1]:57686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hl2sB-00036i-QC for geb-bug-gnu-emacs@m.gmane.org; Tue, 09 Jul 2019 23:02:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33369) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hl2rw-000369-8m for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 23:02:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hl2rt-00072D-Uu for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 23:02:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54074) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hl2rp-0006yn-Rl for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 23:02:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hl2rp-0001vG-K4 for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 23:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Daniel Colascione" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2019 03:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36447 X-GNU-PR-Package: emacs Original-Received: via spool by 36447-submit@debbugs.gnu.org id=B36447.15627276887299 (code B ref 36447); Wed, 10 Jul 2019 03:02:01 +0000 Original-Received: (at 36447) by debbugs.gnu.org; 10 Jul 2019 03:01:28 +0000 Original-Received: from localhost ([127.0.0.1]:34662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hl2rH-0001te-Ju for submit@debbugs.gnu.org; Tue, 09 Jul 2019 23:01:27 -0400 Original-Received: from dancol.org ([96.126.100.184]:54998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hl2rF-0001tT-As for 36447@debbugs.gnu.org; Tue, 09 Jul 2019 23:01:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=6BXW5mQIRfbzWYYcpRj4qxXHYHIIu+FFC4fzz08/tC8=; b=pzIAImH4nBVCTZjYgCZD0c5Iea2yx2m+yvDJy04pApBcHSpHs5ofUWlkyYu15ISLH8D0dOEtOVrynZ5aVc1dAhoaIX9esCZ6vyIjr441IUG0FoFttHCwj9yx3XTi9AX5uAQHOQd/4lZfg9j08fw1fF5TVr/YYNYgocdxHnXvFQszADyO+9R1m96yNa20rAM1G0zkJ8JNRsyEALxmHS6R9vNHMBI7bQtkmOmN0zeHEC258aWN1C5FLmp2SwbSakJZJkB3zCmjr5TGQpW+Pqpboau21MmmZ4j98HsGgKvFY2b+riS9ZZ7+nywWuXW6hWW2xqzEFkgdNwUxZAe8JkS8Ig==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hl2r4-0006m9-AB; Tue, 09 Jul 2019 20:01:14 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Tue, 9 Jul 2019 20:01:14 -0700 In-Reply-To: X-Priority: 3 (Normal) Importance: Normal X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162589 Archived-At: > On Mon, Jul 8, 2019 at 10:25 PM Noam Postavsky wrote: >> I've switched byte-compile-cond-use-jump-table to nil for now, so you >> shouldn't be hitting this anymore. > > Thanks. > >> > I know nothing about this, but did anybody want to fix this in a >> > different way, or did the discussion just peter our? >> >> There were some suggestions about checking PURE_P or similar to see if >> the copy is really needed, but then apparently PURE_P doesn't work at >> all? I've been meaning to check that out, because it seems like there >> are still a few things which aren't making sense. > > It does seem like we've effectively given up pure space when we > switched to pdumper. We still fill it and spend a lot of time making > sure not to waste any, but it's then simply copied to the dump along > with the rest of the dumped image. We're at least combining identical objects, which is what this bug is about. > It's still kept around in the final > executable, so we're wasting quite a bit of disk space on it... At least the executable pure space isn't paged in. I prefer not to waste disk space, but wasting disk space without wasting memory is lower on my list of priorities than other things. > Most importantly, I think, the CHECK_IMPURE macro now does nothing > (except waste a few cycles), and we can freely setcar what should be > purecopied conses. > > (One thing we might do is introduce immutable conses, and use them for > `read', pure space, and in a few other places). We could use pureness information to relocate all the pure objects in the dump so that we're less likely to take COW faults on them during runtime. Right now, if a pure object and a regular object share a page in the dump and we modify the regular object, we copy the pure object uselessly. Note that we're not modifying these objects for GC, since we keep dump markbits separate from the dump image (as we really should be doing for the heap in general one day).