From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: w32/w64 Emacs and gmalloc() Date: Sat, 1 Mar 2014 21:12:01 +0100 Message-ID: References: <831tymwge8.fsf@gnu.org> <834n3hvlkg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2388c11c04704f3912caf X-Trace: ger.gmane.org 1393704749 12752 80.91.229.3 (1 Mar 2014 20:12:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Mar 2014 20:12:29 +0000 (UTC) Cc: monnier , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 01 21:12:35 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 1WJqGt-0007Lq-Af for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 21:12:31 +0100 Original-Received: from localhost ([::1]:60722 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJqGs-0002dU-70 for ged-emacs-devel@m.gmane.org; Sat, 01 Mar 2014 15:12:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJqGo-0002dO-Gd for emacs-devel@gnu.org; Sat, 01 Mar 2014 15:12:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJqGn-00074Q-6c for emacs-devel@gnu.org; Sat, 01 Mar 2014 15:12:26 -0500 Original-Received: from mail-ea0-x229.google.com ([2a00:1450:4013:c01::229]:61341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJqGl-00073c-2O; Sat, 01 Mar 2014 15:12:23 -0500 Original-Received: by mail-ea0-f169.google.com with SMTP id h14so646871eaj.28 for ; Sat, 01 Mar 2014 12:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/0VJOaLVKHBC/8MgpTXN6srZNu4zwDW02ogmrNDaIHM=; b=ilQn7JePpu54kBnyb8qPMTh+YGhevUZBN1MhpVAdKDKg58m8XzrrZlQSU3p6NSQYlf 8Yv1c5X1GQYG2MYZ+/dH348FwcxL/lQ+ST+XSjZRZTAXxTZeDhTyz8/sEcslqVda6o2q zSd1sJDEQroktUlFxJmhreYslYeYJsph1Ec7Myb3bMLT6c7atbeFmHe6qp71vH0m1dY3 iWoWeE6L1Bzunx2uaYDsQlREGOtceeCCEaL8GzeqI98MJml0thy/SNY92AgShI+PiRjo itfg8ui8SkDoxjEbeSHW28ZP7sEetOTLxxuvTJ5dlL4eC//6oKzrq34/yUkJ7OMIVIWr 0m4A== X-Received: by 10.14.88.7 with SMTP id z7mr304508eee.112.1393704742008; Sat, 01 Mar 2014 12:12:22 -0800 (PST) Original-Received: by 10.14.8.196 with HTTP; Sat, 1 Mar 2014 12:12:01 -0800 (PST) In-Reply-To: <834n3hvlkg.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::229 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:170016 Archived-At: --001a11c2388c11c04704f3912caf Content-Type: text/plain; charset=ISO-8859-1 2014-03-01 19:08 GMT+01:00 Eli Zaretskii : > > From: Fabrice Popineau > > Date: Sat, 1 Mar 2014 17:00:18 +0100 > > Cc: Eli Zaretskii , Emacs developers > > > > Only a couple (actualy 5 or 6 at most) of them occur, except during the > > loading of charset maps. > > While loading charset maps, big vectors are allocated and freed right > away > > many times. > > > > What I'm saying is that basically, all those big chunks could be made > > static. > > Are you talking about the big chunks used for charset maps, or about > the rest of them? If the latter, what are they used for? Which code > causes them to be allocated? > The rest of them. When doing 'temacs -batch -l loadup dump' there are 4 occurences before loading the charset maps. They all belong to make-hash-table (gdb) run -batch -l loadup dump Starting program: C:\source\gnu\emacs\mingw\src/temacs.exe -batch -l loadup dump [New Thread 59040.0xb09c] Loading loadup.el (source)... [New Thread 59040.0x113c] #0 e_malloc (size=1120016) at w32heap-new.c:359 #1 0x00000004000f1b21 in lisp_malloc (nbytes=nbytes@entry=1120016, type=type@entry=MEM_TYPE_VECTORLIKE) at alloc.c:893 Lisp Backtrace: "make-hash-table" (0x83edf0) "setq" (0x83ef68) "if" (0x83f058) "load" (0x83f750) (gdb) c They all have the same elisp backtrace, the next sizes are: nbytes=nbytes@entry=560016, nbytes=nbytes@entry=560016, nbytes=nbytes@entry=700040, Then we have a bunch of : Lisp Backtrace: "define-charset-internal" (0x83e398) "apply" (0x83e540) "define-charset" (0x83e770) "byte-code" (0x83e970) "load" (0x83f060) "load" (0x83f750) and then of : Lisp Backtrace: "map-charset-chars" (0x83e7d0) "byte-code" (0x83e970) "load" (0x83f060) "load" (0x83f750) and last 3 occurences of : size=size@entry=786440 Lisp Backtrace: "decode-char" (0x83e798) "byte-code" (0x83e970) "load" (0x83f060) "load" (0x83f750) And after looking more carefully, all those chunks are released before dumping! So I could really handle them differently and shrink the data area which is dumped. Well, unfortunately, maybe it is not a future proof assumption. Fabrice --001a11c2388c11c04704f3912caf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2014-03-01 19:08 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:<= br>
> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Sat, 1 Mar 2014 17:00:18 +0100
> Cc: Eli Zaretskii <eliz@gnu.org= >, Emacs developers <emacs-dev= el@gnu.org>
>
> Only a couple (actualy 5 or 6 at most) of them occur, except during th= e
> loading of charset maps.
> While loading charset maps, big vectors are allocated and freed right = away
> many times.
>
> What I'm saying is that basically, all those big chunks could be m= ade
> static.

Are you talking about the big chunks used for charset maps, or about<= br> the rest of them? =A0If the latter, what are they used for? =A0Which code causes them to be allocated?

The rest of them.= =A0
When doing 'temacs -batch -l loadup= dump'
there are 4 occurences before lo= ading the charset maps.
They all belong to make-hash-table

(gdb) run -batch -l loadup dump
Sta= rting program: C:\source\gnu\emacs\mingw\src/temacs.exe -batch -l loadup du= mp
[New Thread 59040.0xb09c]
Loading loadup.el (source)...
[Ne= w Thread 59040.0x113c]

#0 =A0e_malloc (size= =3D1120016) at w32heap-new.c:359
#1 =A00x00000004000f1b21 in lisp_malloc (nbytes=3Dnbytes@entry=3D11200= 16,
=A0 =A0 type=3Dtype@entry=3DMEM_TYPE_VECTORLIKE) at alloc.c:8= 93
Lisp Backtrace:
"make-hash-table&quo= t; (0x83edf0)
"setq" (0x83ef68)
"if" (0x83f058)
<= div>"load" (0x83f750)
(gdb) c

They all have the same elisp backtrace, the next sizes are:
nbytes=3Dnbytes@entry=3D560016,
nbytes=3Dnbytes@entry=3D= 560016,
nbytes=3Dnbytes@entry=3D700040,

Then we have a bunch of :
Lisp Backtrace:
= "define-charset-internal" (0x83e398)
"apply" (0x83e540)
"define-charset" (0x8= 3e770)
"byte-code" (0x83e970)
"load"= ; (0x83f060)
"load" (0x83f750)

and then of :
Lisp Backtrace:
"map= -charset-chars" (0x83e7d0)
"byte-code" (0x83e970)<= /div>
"load" (0x83f060)
"load" (0x83f750)=

and last 3 occurences of :
size=3D= size@entry=3D786440
Lisp Backtrace:
"decode-ch= ar" (0x83e798)
"byte-code" (0x83e970)
&q= uot;load" (0x83f060)
"load" (0x83f750)

And after l= ooking more carefully, all those chunks are released before dumping!
<= div>So I could really handle them differently and shrink the data area whic= h is dumped.
Well, unfortunately, maybe it is not a future proof assumption.
<= div>
Fabrice



--001a11c2388c11c04704f3912caf--