From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Samuel Bronson Newsgroups: gmane.emacs.devel Subject: Re: Dumper problems and a possible solutions Date: Wed, 25 Jun 2014 16:53:58 -0400 Message-ID: References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> <831tucrguf.fsf@gnu.org> <20140625183241.GW179@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1403729654 1131 80.91.229.3 (25 Jun 2014 20:54:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 20:54:14 +0000 (UTC) Cc: Eli Zaretskii , Dmitry Antipov , emacs-devel@gnu.org To: Rich Felker Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 25 22:54:07 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WzuCl-00019w-BX for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 22:54:07 +0200 Original-Received: from localhost ([::1]:40943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzuCk-0005w2-Tj for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 16:54:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzuCh-0005vk-MI for emacs-devel@gnu.org; Wed, 25 Jun 2014 16:54:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzuCg-0002Sh-I5 for emacs-devel@gnu.org; Wed, 25 Jun 2014 16:54:03 -0400 Original-Received: from mail-la0-x22c.google.com ([2a00:1450:4010:c03::22c]:64779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzuCf-0002S2-2s; Wed, 25 Jun 2014 16:54:01 -0400 Original-Received: by mail-la0-f44.google.com with SMTP id ty20so1193642lab.31 for ; Wed, 25 Jun 2014 13:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TnxjIU2APKyQwLpoD5+DUXBWFK7kS4k2BCx4Keud65I=; b=Nx+dMd4BJbPqzP++IUAXeRmfoLLEybEFLb1fZoyWbKG5Gh/jLLbR7DazPevVtTGlW8 Mm9EOuTdRADSvyxpwBqZ9thayFCn0mh22BhiemNEQj6xibZI0oQWAYA4OsNHae7JSqwR i4BOq0Gt2Ws5a9hAC7CnMYBUAXyhw4VgKd8A1YXyfBVIIVY+mNgm3r1GbE2OOV850adt gh26HgI9976nmYsBceUYKaXSzsWERu95G1qSF+cDjEd7p4VQj4VKGvLbyNQQRLzivcBV 6T8PC4KwlQqXVAOX2sxX2n5zIu5JV3hP5rJB4spqXGk+pFD/fDdJTWObt/WmmZ3OKtVv Nc7Q== X-Received: by 10.112.76.66 with SMTP id i2mr7214720lbw.37.1403729638653; Wed, 25 Jun 2014 13:53:58 -0700 (PDT) Original-Received: by 10.112.64.68 with HTTP; Wed, 25 Jun 2014 13:53:58 -0700 (PDT) In-Reply-To: <20140625183241.GW179@brightrain.aerifal.cx> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172729 Archived-At: On 6/25/14, Rich Felker wrote: > In musl's malloc, we use brk if it's available (note: with PIE, most > kernels give you almost no available brk space due to the way the > mappings are laid out) [...] Yeah, that tiny gap has bitten in other ways, too: talks about a stack overflow with the same cause; I really think the kernel should stop doing that. > Also, musl does not provide a working sbrk at all, since synchronizing > with an application's use of sbrk would introduce performance costs > into all correct applications that don't poke at the brk. Looking at the manpage, I can't really follow how having sbrk() would involve a slowdown in everything? Do you mean that musl's malloc gets a speed bonus out of assuming it's the sole user of brk()/sbrk(), and thus the whole region from the initial brk()point to the current brk()point is belongs to it? (Yeah, all (potentially) 125 MiB - stacksize of it!)