From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Hendrik Tews Newsgroups: gmane.emacs.bugs Subject: bug#42013: 26.3; hash tables are not garbage collected Date: Wed, 21 Oct 2020 14:47:45 +0200 Message-ID: <874kmnoidq.fsf@cert.kernkonzept.com> References: <87zh8uwxn3.fsf@cert.kernkonzept.com> <87a6wlt98n.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22998"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: 42013@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 21 14:48:24 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kVDXT-0005u8-Rm for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Oct 2020 14:48:23 +0200 Original-Received: from localhost ([::1]:34382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kVDXS-0006fy-NK for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Oct 2020 08:48:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kVDX8-0006fS-JN for bug-gnu-emacs@gnu.org; Wed, 21 Oct 2020 08:48:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36649) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kVDX8-00074c-AS for bug-gnu-emacs@gnu.org; Wed, 21 Oct 2020 08:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kVDX8-0004Qs-8d for bug-gnu-emacs@gnu.org; Wed, 21 Oct 2020 08:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Hendrik Tews Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Oct 2020 12:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42013 X-GNU-PR-Package: emacs Original-Received: via spool by 42013-submit@debbugs.gnu.org id=B42013.160328447317023 (code B ref 42013); Wed, 21 Oct 2020 12:48:02 +0000 Original-Received: (at 42013) by debbugs.gnu.org; 21 Oct 2020 12:47:53 +0000 Original-Received: from localhost ([127.0.0.1]:48195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kVDWz-0004QV-DH for submit@debbugs.gnu.org; Wed, 21 Oct 2020 08:47:53 -0400 Original-Received: from serv1.kernkonzept.com ([159.69.200.6]:37703 helo=mx.kernkonzept.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kVDWy-0004QN-0A for 42013@debbugs.gnu.org; Wed, 21 Oct 2020 08:47:52 -0400 Original-Received: from ip5f5a64b2.dynamic.kabel-deutschland.de ([95.90.100.178] helo=cert) by mx.kernkonzept.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) id 1kVDWw-0000iZ-Re; Wed, 21 Oct 2020 14:47:50 +0200 Original-Received: from localhost ([::1] helo=cert) by cert with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kVDWw-000A85-EY; Wed, 21 Oct 2020 14:47:49 +0200 In-Reply-To: <87a6wlt98n.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 17 Oct 2020 12:52:40 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191162 Archived-At: Lars Ingebrigtsen writes: > => ((vec2 -1) (vec1 4)) > > Uhmn... It is not really clear what you executed to obtain the negative number. I am assuming you executed all the let expressions in your reply in sequence. To me, the most obvious explanation for the negative number would be that garbage-collect does not always perform a full garbage collection, therefore the last garbage-collect by chance finally performs a full collection and collects one vector that has survived the other garbage collections... > So I'm not sure there's anything to fix here, except perhaps noting in > the doc string that you can't do precision math on the numbers? Anybody? To me the observed behavior suggests that the Elisp garbage collector is more complicated than the simple mark and sweep described in the manual. Can you really confirm, that this is not the case? Because otherwise I would expect a documentation update for garbage-collect and in the Garbage Collection appendix. Hendrik