Re: w32/w64 Emacs and gmalloc()

[Fabrice Popineau]

2014-03-01 19:08 GMT+01:00 Eli Zaretskii <address@hidden>:

> From: Fabrice Popineau <address@hidden>
> Date: Sat, 1 Mar 2014 17:00:18 +0100
> Cc: Eli Zaretskii <address@hidden>, Emacs developers <address@hidden>

>
> 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 (address@hidden,

    address@hidden) 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:

address@hidden,

address@hidden,

address@hidden,

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 :

address@hidden

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