From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Failing to GC killed buffers considered harmful Date: Tue, 31 Mar 2020 15:20:03 -0400 Message-ID: References: <838sjj5jg9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="126862"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , Daniel Colascione , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 31 21:20:52 2020 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 1jJMRP-000Wuq-KG for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 21:20:51 +0200 Original-Received: from localhost ([::1]:43340 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJMRO-00053r-MY for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 15:20:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37898) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJMQn-0004YP-O0 for emacs-devel@gnu.org; Tue, 31 Mar 2020 15:20:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jJMQl-00083g-Ry for emacs-devel@gnu.org; Tue, 31 Mar 2020 15:20:13 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6535) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jJMQk-00080j-4d; Tue, 31 Mar 2020 15:20:10 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AF05D81CD3; Tue, 31 Mar 2020 15:20:08 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E91268136B; Tue, 31 Mar 2020 15:20:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1585682406; bh=41qg+v1i9yksK3WVKMjXVggEqfxilnr9gDXCj2S+jrM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=QG02FW8DoUJPzfOIkGytQoMuXNZ+olEmhNAZGvpvW56j3COTpEiKUAyZpBzF/ky9B pgDC+GfICPBhIHpxpyCbbZZVNUVbdnjgSVzBjZ2thhCMxIGVGmi+Alclp9ZSZB38VY ra0OaY+q1PQO8nWEFFXW9NavdGZ7/oLp9XoxIACW1HKkjY60U3qZLQC5yO7oXXyBgq 19hC8hl8T5y5NKWnXoVs8Lpw4fJcM2hKo5S6BI6qqzU7T5ZCaUqID5HEfRAdpBcQCg KxS3dsTfCy9I8ggcTKgoUKa8W1xHFHNXVFqexJmv2JgamyK+e5uKIFkSauB5zbtbAm KzQjN/JlPE2vw== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 29F071205FB; Tue, 31 Mar 2020 15:20:06 -0400 (EDT) In-Reply-To: (Pip Cet's message of "Tue, 31 Mar 2020 18:23:40 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246151 Archived-At: >> > buffer text. >> The buffer text is not stored within the `struct buffer` object, so no. > struct buffer_text, I meant. Ah, right. We do have pointers into that substructure coming from indirect buffers. These should all be accompanied by a `base_buffer` pointer to the head of the `struct buffer`, so it's not 100% crucial that we take those inner pointers into account, but yes, it does mean that inner pointers into `struct buffer` are probably more likely than for other pseudovectors. Luckily, Paul's code already takes care of inner pointers into pseudovectors, so we're good in either case. > Well, I have created temporary buffers to act as, essentially, mutable > strings. I see no reason I have to kill > expensively-but-efficiently-implemented mutable strings explicitly > before having them collected! More seriously, I do think making > buffers more lightweight would be a good thing, perhaps even having an > immutable string without text properties/mutable string with gap and > some buffer properties/full-blown buffer spectrum. You don't have to convince me. I just haven't tried to solve this long-standing need, and it's a can of worms, I think. > (As I realize someone here usually demands use cases: I'd like to fix > the hash table printing code to print hashes predictably. That > requires sorting their keys by something predictable. Their printed > presentation is usually good enough, but that requires > prin1-to-string, which uses a buffer. It's currently too slow.) Have you tried to profile it to see where the time is spent, to have a vague idea of what kind of slimming regime we'd need to impose to our buffers before it becomes tolerable? In any case, printing-then-sorting doesn't sound like a good plan: I think it's inherently inefficient. >> Indeed, my patch doesn't have anything to do with the original problem, > I don't see how the original problem would fail to be solved by your patch. Oh, maybe it would, but that was definitely not my motivation. > Pdumper doesn't dump all objects that survive GC, only those it > can reach from the heap (plus some collateral damage). So your patch > restores that requirement precisely, and we can keep the assert() > unless we decide we want to relax our standards and allow killed > buffers during the dump. I think if we want to re-introduce this assert, we should add a matching test during pdump. Stefan