From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Changes in GC and in pure space (was: [Emacs-diffs] master 5d4dd55: Fix lifetime error in previous patch) Date: Mon, 22 Jul 2019 19:05:43 +0000 Message-ID: References: <20190721193221.1964.53182@vcs0.savannah.gnu.org> <20190721193222.8C19E20BE2@vcs0.savannah.gnu.org> <83blxmqfkq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="118111"; mail-complaints-to="usenet@blaine.gmane.org" Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 22 21:06:34 2019 Return-path: Envelope-to: ged-emacs-devel@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 1hpddq-000UbD-2l for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2019 21:06:34 +0200 Original-Received: from localhost ([::1]:36868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpddp-0008Ni-3E for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2019 15:06:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53131) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpddg-0008Nc-Qc for emacs-devel@gnu.org; Mon, 22 Jul 2019 15:06:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hpddf-0004gt-K2 for emacs-devel@gnu.org; Mon, 22 Jul 2019 15:06:24 -0400 Original-Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]:36673) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hpddd-0004ff-Ao; Mon, 22 Jul 2019 15:06:21 -0400 Original-Received: by mail-ot1-x332.google.com with SMTP id r6so41385982oti.3; Mon, 22 Jul 2019 12:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hj5wrpHXxPUOgIQmoh52mkdItUyqjfgg2NdTjp63l58=; b=et+reaz5wtDL8vOix4J4KJlk0CPqrIh5kw1CZsBfhTjgTLO+nQXEjbGTDSIILacn6g rliLNyUnzv/p7pslSTwcsdNw0SM0MX/Jyq5+quzEscOr/CJAjd9aq8m0If5NoQ2SDgyO sfEmHWh7vU05iDaftqVWpM6BesSpHCeg/agrQk0A3ZSoBkxKmYX6PPIo+oiry7nSaW/V qe7ozDo8baNFhKiTNJssfQTyOjhz+CbvsbRh5/jGWVIIoOj1bcMRK6Kv/Yv7WpSpeFEH RiC0c1rqO9FBPjxG9x41g1tUt8ZKcrEyRhY7rlTMZUMXJgHElue7shiscHv7L51KRSkd ldzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hj5wrpHXxPUOgIQmoh52mkdItUyqjfgg2NdTjp63l58=; b=sPMn1VFFLqzz/YJc6MDyQGJpi6hfdzqVsOv5X3syN0yV8UUh+F5NT+bQg2qcB36vm8 gSQWrlk8vIIbnrBUDyTRPLoEK8tEZzibwYsBJM7cGrOy8mXeMT1+ZZo88Y4gepT6sThF BJt/RT5GlI+R4DBxIDVj9TwTEINUKe4gwq9cX5PKzurAE8ylzjTNVeXeAFRxwrxes8s9 TJnenAC0J3eHX0mxpQQxyc1i+xTC46jZhUCbAlElGFMybPaIkfAbr/j33ToujZl6MWel P6A8oI0IBCWFMnlIcs4mSOx/up0suFb/s58cpsCHP1U8/bEe6R8C42r0ULtTDjMNB4/V O+ag== X-Gm-Message-State: APjAAAVv+Fncfj63QuCjA5fdzq+EVwpgaGiyMl1XaPbOL2aXibCKdkHQ DEUFkSqzGmCuFvkrSb5F+f8fyDcbRBEWtqeDZ2lbQA== X-Google-Smtp-Source: APXvYqzg5NJjfoDn3c8umzryIcUw0F2XVwL4K4nkd4jzWHCHQSM/F9YaA1TCbZzOBDJiiPphGPgaQ5vYyyqacx0h0VU= X-Received: by 2002:a9d:2901:: with SMTP id d1mr31551755otb.154.1563822379873; Mon, 22 Jul 2019 12:06:19 -0700 (PDT) In-Reply-To: <83blxmqfkq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::332 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238803 Archived-At: On Mon, Jul 22, 2019 at 3:01 PM Eli Zaretskii wrote: > Please be aware that these changes might potentially affect the > schedule of the Emacs 27 release. Thank you for keeping that in mind. I don't think we should delay the Emacs 27 release, and I understand completely if we have to delay improvements until Emacs 28. > Emacs 27 has accrued many new features and important improvements, and > has proven to be generally very stable. My intentions were to start > its pretest in the September-October time-frame, with the goal of > releasing Emacs 27.1 a few months later. That sounds like a good schedule to me. > Your changes in GC, which is a very delicate part of Emacs, might > affect its stability and force us to analyze and fix hard-to-debug > crashes, and thus postpone the beginning of the pretest and the > subsequent release. I think we should try to avoid postponing the > 27.1 release, what with the many new features it will give our users. I think this is mostly directed at Paul, but I agree major GC changes should wait until Emacs 28. I can't think of a really good example, but I think the bug that triggered this discussion will have to do: had it remained undiscovered, we would have seen very strange and unpredictable behavior indeed; some Emacs sessions that fail to GC and run out of memory, and some sessions that GC at every maybe_gc call. > The same goes for removing the pure space, IMO: another core feature > whose existence and traits many parts of Emacs came to take for > granted. Let's not remove pure space for Emacs 27. (The traits of pure space changed significantly, with the introduction of pdumper: CHECK_IMPURE is now a nop rather than a valuable debugging aid, and PURE_P is always false. That is something we should mention somewhere, along with all the good NEWS, because it will make Emacs 27 harder to maintain. But that's all we should do, I think, document the odd state we're in now and resolve to change it when it is more appropriate to do so.) > I'm all for improving GC and simplifying our memory management, but > please keep the above in your minds when you play with this stuff. > Especially as, judging by the changes you are making, the details and > indeed some of the aspects of the idea of the changes, are not yet > sufficiently clear/finalized. I'm forced to agree, as far as my ideas are concerned. Eager rehashing of hash tables: needs to be timed precisely right for user-defined dumped hash tables to work, as Paul apparently wants them to, and my current proposal isn't (but let's fix Fclrhash to work on non-rehashed hash tables). Hash tables without internal free vectors: change the interpretation of the hash table API (:size has to be reinterpreted to remain meaningful), and some trade-offs about when to use hash tables. Four tag bits for "annotated" (e.g., immutable) objects: very far from ready, and problematic on 32-bit machines (perhaps this is no longer a concern for Emacs 28...) Turning pseudovectors into their own tag type, as miscellaneous objects: not convinced it's worth the change, yet. > An alternative would be to make these changes on a branch, and merge > that branch when it is sufficiently stable and mature. Please > consider this possibility. After all, these two issues are not > terribly urgent to fix (unlike, say, the unexec thingy). I'm not quite sure which "unexec thingy" you're referring to. Here are things I would consider urgent enough to warrant looking at for Emacs 27: - remove code like we have in `Ffset' to detect GC bugs that presumably have been fixed by now - make_fixnum called for numbers outside the fixnum range - various places that should detect circular lists but don't (lread.c reading hash tables, for example) - doubly-evaluated macro arguments (the one I can think of offhand is DUMP_SET_REFERRER, which is harmless, but others might not be) - since we appear to be stuck with lazy rehashing for now, the various bugs this causes (I mentioned Fclrhash above)