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 13:15:15 +0300 Message-ID: <83zilu3vf0.fsf@gnu.org> References: <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> <83h9825jaj.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477304363 2619 195.159.176.226 (24 Oct 2016 10:19:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 10:19:23 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 12:19:20 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 1bycLN-0006a8-I1 for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 12:19:01 +0200 Original-Received: from localhost ([::1]:45686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bycLP-0004lg-UK for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 06:19:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bycHu-0002xS-6N for emacs-devel@gnu.org; Mon, 24 Oct 2016 06:15:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bycHt-00049W-D4 for emacs-devel@gnu.org; Mon, 24 Oct 2016 06:15:26 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bycHm-00045u-Sr; Mon, 24 Oct 2016 06:15:18 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1740 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bycHk-00041r-Ur; Mon, 24 Oct 2016 06:15:17 -0400 In-reply-to: <83h9825jaj.fsf@gnu.org> (message from Eli Zaretskii on Mon, 24 Oct 2016 09:54:12 +0300) 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:208671 Archived-At: > Date: Mon, 24 Oct 2016 09:54:12 +0300 > From: Eli Zaretskii > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > > And maybe there are other possibilities. We really need to come up > with all the possible ideas, try which ones work, and decide as > quickly as possible what is the best one. This currently is the most > serious blocking issue on the way towards releasing Emacs 25.2 soon, > as we wanted to. So I think the most promising alternatives at this point are: . Build with gmalloc but without ralloc. Would people who have ralloc.o in their src directory please reconfigure with REL_ALLOC=no, and see if the result works reliably in you're day-to-day work? Please report the results here, and if you were hit by one of the related bugs (24358 and 24764), please report also to the corresponding bug addresses. . 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. If one of these works, we should consider reverting the changes in regex.c that attempt to handle relocation during regex.c calls. We should also consider removing ralloc.c from any of our builds, in the hope that the platforms which we care about have a much better malloc implementation than what was available 20 years ago. Comments?