From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Failing to GC killed buffers considered harmful Date: Sun, 29 Mar 2020 12:06:56 -0700 Message-ID: <5089e383-7b34-d9d6-a002-26312c5f3066@dancol.org> References: <838sjj5jg9.fsf@gnu.org> <83r1xb3sbg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="129112"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: pipcet@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 29 21:09:38 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 1jIdJS-000XUH-MF for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 21:09:38 +0200 Original-Received: from localhost ([::1]:40598 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIdJR-0000xl-KH for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 15:09:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33562) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIdH5-0007jh-G3 for emacs-devel@gnu.org; Sun, 29 Mar 2020 15:07:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIdH4-0003HE-8P for emacs-devel@gnu.org; Sun, 29 Mar 2020 15:07:11 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:44194) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jIdH3-0003Ex-LN; Sun, 29 Mar 2020 15:07:10 -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:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=9AutUmz+HIDR/x+NS73EAtt2Azy7TFD/aKDz/6dt/58=; b=icbGgpw95wIRFY34UT/+xyERUy eBH2Ko+4HmCNcVL+N4IGT1JyDE1lKxqyH3/Lv/Kn32bDk8CiwIA0wICqEzblZ9RzJS5L3r2yXI4z6 3oqn3A++TzP66yfRRBgocFjH/F5qMlqAFuhqE4fk4k/O0hSOeu+CJ2HuYvRtWTkHXX/VonG7sLBE5 P51ZPUei/iGJNwSWlwwR8uJ6rcUrWlaIyPnp/32ONu2rhxb8nEnO+s919mo9C+4vR/iPTGLQZLsds Hh3m5NwwxN6+NL9s0YozZ66lKVv0fS00PLVeB9d6TWNyR/iJ/nvKrZG8VtwSINcD3m4ReoOKtxpww G/C+CIxA==; Original-Received: from [2604:4080:1321:9a00:2cc1:3fc1:de17:9423] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jIdH0-0001IU-Ut; Sun, 29 Mar 2020 12:07:06 -0700 In-Reply-To: <83r1xb3sbg.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:245966 Archived-At: On 3/29/20 11:54 AM, Eli Zaretskii wrote: >> From: Stefan Monnier >> Date: Sun, 29 Mar 2020 12:45:48 -0400 >> Cc: Daniel Colascione , Pip Cet , >> emacs-devel@gnu.org >> >> Could we try and write out buffers such that they are read back as >> something else (e.g. a special record with type `dead-dumped-buffer`)? > > What problem will that solve? > > The other buffers that we inherit from temacs are all frequently-used > ones, so it makes sense to keep them. A killed buffer isn't useful, > by contrast. > > We could perhaps avoid dumping buffers altogether, and instead create > them all at startup, but it will probably also cause complications, > e.g., because the frame we dump must have a window, which must have a > buffer. I hope that avoiding to dump that one buffer, even if that > requires to add support for this in pdumper.c, will be easier. > None of these measures is necessary. There's nothing special about a killed buffer: such a thing is just a lisp buffer object in a specific state. We just need to make sure that dumping buffer objects in this state works. The right approach isn't to prohibit dumping buffers generally for some reason. And yes, you do have to dump killed buffers. If we have a Lisp reference to a buffer and we can't dump buffers, what do we do? Fail the dump? Replace the reference with the integer 5? Yes, if we just remove the assertion, we'll end up with a dead buffer that's constantly marked because it lives in the pdumper image. So what? All pdumper objects are immortal. (But objects on clean pages do get evicted from memory eventually.) Connecting buffer death to GC at all is just wrong. When we kill a buffer, we nuke the buffer's character array and interval tree and put the Lisp buffer object in a dead state. Then that object remains live (from Lisp POV) until its last reference disappears, at which point we reclaim the Lisp object. A buffer should be no different from any other pseudovector in this respect.