From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Mattner Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Sat, 26 Nov 2011 20:09:36 +0100 Message-ID: References: <4ED0F945.5090805@yandex.ru> <4ED127C0.4030904@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1322334590 25969 80.91.229.12 (26 Nov 2011 19:09:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2011 19:09:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 20:09:46 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RUNdA-0003ju-U5 for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 20:09:45 +0100 Original-Received: from localhost ([::1]:58155 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUNd9-00023y-K0 for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2011 14:09:43 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUNd7-00023s-Ca for emacs-devel@gnu.org; Sat, 26 Nov 2011 14:09:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUNd5-0007cc-BV for emacs-devel@gnu.org; Sat, 26 Nov 2011 14:09:41 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:39553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUNd4-0007cU-Oi for emacs-devel@gnu.org; Sat, 26 Nov 2011 14:09:39 -0500 Original-Received: by iaek3 with SMTP id k3so8195657iae.0 for ; Sat, 26 Nov 2011 11:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FHEqBZt/kKIOPOIouXCmxjLyNG08d3F+MlVspTZnExE=; b=ZF2TO2R1waKw1coUDRWkkFD4g9AWRFsjJsN6Ayw8PXfQzkbHYnczmG2uFf9txjkek4 smiZNbms7UO1rmDPGu2eYaKT5XDTbosPpCbd3khq1SAN+GzaF73tXP2xunKTioqxQbdP dYSjE3/zUyhan8hwxHx6Mu+jsfTAdBefVUBWA= Original-Received: by 10.50.89.227 with SMTP id br3mr47041887igb.14.1322334576504; Sat, 26 Nov 2011 11:09:36 -0800 (PST) Original-Received: by 10.50.190.167 with HTTP; Sat, 26 Nov 2011 11:09:36 -0800 (PST) In-Reply-To: <4ED127C0.4030904@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:146267 Archived-At: On Sat, Nov 26, 2011 at 6:54 PM, Dmitry Antipov wrote: > On 11/26/2011 06:58 PM, Carsten Mattner wrote: > >> Allow me to be naive and ask this: what about compaction? > > Compaction implies the moving of live objects, which means that you > should be able to find _all_ pointers to such objects and update them. > Emacs GC has no such features, but it's technically possible > to enhance mark/sweep GC to do some heap compaction. The GC I deal with most is Erlang's and it's using a copying gc algo where the heaps are usually plenty and small enough to make GC in 999 out of 1000 times to be unnoticeable that if it's noticeable you found an inefficient piece of your own code. I don't have as much real life experience with Sun's JVM or other popular vms' GCs. >> Would the allocator in use fragment the overall system memory >> space if it frees more aggressively? > > If you want to ask 'if we will run GC more often, will it reduce > heap fragmentation', the answer is most probably 'no'. You can try > to play with 'gc-cons-threshold' and 'gc-cons-percentage' and see > what happens. But, in general, heap fragmentation issues can't be > solved this way. > > Other possible meanings of 'more aggressively' makes no sense for > simple (non-generational, non-incremental) mark/sweep GC since it > _always _ marks all live data and _always_ sweeps the whole > Lisp data regions of the heap. My question was about doing many tiny alloc/free calls and fragmenting the kernel vm. Do applications like Emacs have to consider that and do large as in 2x as required-but-not-available "just-in-case-I-need-more" allocations? > If you're looking for good introduction to GC stuff, I would > recommend ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps. Thanks.