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 11:47:26 +0300 Message-ID: <8337jm5e1t.fsf@gnu.org> References: <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477298871 14417 195.159.176.226 (24 Oct 2016 08:47:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 08:47:51 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 10:47:46 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 1byauu-0001of-FV for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 10:47:36 +0200 Original-Received: from localhost ([::1]:45286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byauv-0005bN-NT for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 04:47:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byaup-0005b7-EP for emacs-devel@gnu.org; Mon, 24 Oct 2016 04:47:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byaum-0000l7-Bh for emacs-devel@gnu.org; Mon, 24 Oct 2016 04:47:31 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byaum-0000l2-9G; Mon, 24 Oct 2016 04:47:28 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1420 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byaul-0006wa-HZ; Mon, 24 Oct 2016 04:47:28 -0400 In-reply-to: (message from Andreas Schwab on Mon, 24 Oct 2016 10:29:35 +0200) 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:208666 Archived-At: > From: Andreas Schwab > Cc: Paul Eggert , emacs-devel@gnu.org > Date: Mon, 24 Oct 2016 10:29:35 +0200 > > On Okt 24 2016, Eli Zaretskii wrote: > > > I don't remember well enough the internals of ralloc.c: perhaps it > > doesn't relocate Lisp string data unless the string is long enough? or > > at all? So the problems with Lisp string might not be as grave as I > > fear, but this should certainly be looked into before we dismiss all > > those cases. > > String data can be relocated even without ralloc, see > compact_small_strings. Yes, but that's called only by GC, so not a problem in most (if not all) the places I've seen that, and is not related to ralloc anyway. Looking at ralloc.c and its callers, I think the only blocks of memory it relocates on its own are those allocated with r_alloc or r_realloc, which is only used for buffer text and (under REGEX_MALLOC) for regex.c failure stack. Which means compact_small_strings is the _only_ place where string data is relocated, so just calls to malloc cannot. IOW, I confused GC and compact_small_strings with ralloc, when I talked about string data, and our only problem is with pointers to buffer text. Am I missing something? Thanks.