From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Wed, 22 Jun 2022 15:59:07 +0300 Message-ID: <83k098kg6c.fsf@gnu.org> References: <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87bkur72b7.fsf@gnus.org> <874k0j40e7.fsf@gnus.org> <871qvm16he.fsf@gnus.org> <83a6aanm5j.fsf@gnu.org> <87o7yozzj0.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19996"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, yantar92@gmail.com, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 22 15:02:42 2022 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 1o400I-0004vd-Bs for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Jun 2022 15:02:42 +0200 Original-Received: from localhost ([::1]:38472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o400H-0006FC-Dy for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Jun 2022 09:02:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37456) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3zx4-0004UB-Q2 for emacs-devel@gnu.org; Wed, 22 Jun 2022 08:59:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41040) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3zx3-0006td-NC; Wed, 22 Jun 2022 08:59:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Dvz1pe34u5/mBzpkyFXi+pKWBOuzvrIkrtI6gn/JrCs=; b=q7gXfSQFXnerVe4FYlWk PZxxMu4firYSm50cZ5jKa+wPhhczvvY+zg6gVX0MWPYnWo5HhQuJWXE6IvaUqAvvgCFmPvoGcup5B 4+yLX0396cnXcIpMcykLFpnc3TFwaMBgD2DSveC2vKmaWYijC2LBladh11qHS3s0C0fTf7m5Jv9HP 2R+fWWs/gpJrFLfbloH5PFZjo+mP+6BQN1ky7P0nNamOPcGTO9SuJzlDoUz1mrbFQj7QXLsiofqJP Qm6gXJXDXQWFmRw34UCOsj0Tw9fq0AqJL00437zuB+4BQ5z9vn0fGRCcbrrMUM877NAhRuDqoGErA fwztlCJsuNMk5w==; Original-Received: from [87.69.77.57] (port=4154 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3zx0-0003GY-6F; Wed, 22 Jun 2022 08:59:19 -0400 In-Reply-To: (message from Lynn Winebarger on Tue, 21 Jun 2022 20:01:43 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:291509 Archived-At: > From: Lynn Winebarger > Date: Tue, 21 Jun 2022 20:01:43 -0400 > Cc: Eli Zaretskii , Stefan Monnier , > Ihor Radchenko , Mattias Engdegård , > Tim Cross , rms@gnu.org, Alan Mackenzie , > emacs-devel > > For some reason, the configure script chooses not to use mmap for malloc. The configure script chooses not to use mmap directly because glibc's malloc already does that internally where it decides that to be beneficial, and because using mmap directly has some disadvantages we'd like to avoid if possible. > jemalloc is designed to use mmap as much as possible So is glibc. > so it isn't limited to freeing only the uppermost regions. Neither is glibc, although it uses different algorithms. > I can't tell what (if any) option allows me to overrule the configure > scripts decision to use sbrk instead of mmap. You don't want that, not on GNU/Linux systems. We switched away of sbrk and mmap for several good reasons. > Are there any formal memory-allocation/reclamation benchmarks that I should > use instead of this ad hoc task? Not that I know of.