From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Mon, 24 Oct 2016 19:39:01 +0300 Message-ID: <83zilt3dne.fsf@gnu.org> References: <87k2djwumn.fsf@users.sourceforge.net> <83h98nidvd.fsf@gnu.org> <87eg3rvtsf.fsf@users.sourceforge.net> <83k2dihpm9.fsf@gnu.org> <8760p2wzgj.fsf@users.sourceforge.net> <838ttyhhzu.fsf@gnu.org> <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <8360ojpndr.fsf@gnu.org> <83wpgzo30m.fsf@gnu.org> <5a4bbe6d-08ce-e6c6-39d1-49c9cd6d1ffd@cs.ucla.edu> <83mvhvns9a.fsf@gnu.org> <83d1irnozo.fsf@gnu.org> <83mvhunb0d.fsf@gnu.org> <423fab24-9be6-778c-58c3-29a0b825b8c7@cs.ucla.edu> <83a8du5gy1.fsf@gnu.org> <92ca0bf8-7ad4-a7de-70e5-ddbd6eab9741@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477327187 18325 195.159.176.226 (24 Oct 2016 16:39:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 16:39:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 18:39:43 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1byiHP-0001z2-W2 for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 18:39:20 +0200 Original-Received: from localhost ([::1]:48107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byiHR-0003yg-RP for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 12:39:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byiHF-0003ve-5Q for emacs-devel@gnu.org; Mon, 24 Oct 2016 12:39:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byiHA-0000a7-Ly for emacs-devel@gnu.org; Mon, 24 Oct 2016 12:39:09 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byiHA-0000a3-Ie; Mon, 24 Oct 2016 12:39:04 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3275 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byiH9-0008PY-Su; Mon, 24 Oct 2016 12:39:04 -0400 In-reply-to: <92ca0bf8-7ad4-a7de-70e5-ddbd6eab9741@cs.ucla.edu> (message from Paul Eggert on Mon, 24 Oct 2016 09:21:50 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:208705 Archived-At: > Cc: emacs-devel@gnu.org > From: Paul Eggert > Date: Mon, 24 Oct 2016 09:21:50 -0700 > > On 10/24/2016 12:44 AM, Eli Zaretskii wrote: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358... Then there's > > bug#24764 ... > > These bugs seem to be fixed now (thanks to you!). Some of them are fixed. At least one more remains (I hope to fix it soon). What's more, we still don't know whether the changes in regex.c by Noam are correct enough to solve the problems with relocation of buffer text while we search the buffer, and we also don't know yet whether the two bugs mentioned above are solved because we didn't hear from their OPs. Since these all are related to ralloc.c, the question is whether we should get rid of using it on GNU/Linux, instead of chasing each of these problems (which is anything but easy and might take time). > As Andreas pointed out, the problems with ralloc.c are not as severe > as initially feared, since they should be limited to pointers to > buffer text and should not extend to pointers to Lisp strings. Indeed, and that's a relief. > As I understand it, although the ralloc.c approach worked for a long > time, it fell out of favor on common platforms and so hasn't been > debugged as thoroughly for the past several years. Unfortunately, recent > changes to glibc have caused ralloc.c to be used again on common GNU > platforms and this are shaking out longstanding bugs with the ralloc.c > approach. This means people using bleeding-edge glibc are suffering > problems similar to what people on now-unusual platforms must have had > for some time. Yes, exactly. And since most people at least here use Emacs on GNU/Linux, the nasty problems due to ralloc.c are popping up much faster and more frequently than they did when only *BSD and Windows used ralloc.c. > Surely we can fix these ralloc.c-related bugs as they come up. That > being said, they are a hassle for users and maintainers, and if dropping > ralloc.c works and doesn't cause significant performance degradation it > sounds like that would be a win. Right, so I'd like your opinion and comments about the possible solutions proposed so far: . Build with gmalloc but without ralloc. . Back-port the HYBRID_MALLOC changes from master. Not sure if the patch is simple and safe enough, or whether the result is tested well enough to have that on emacs-25. . Build with gmalloc and use mmap for buffer text allocation. Thanks.