[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: w32/w64 Emacs and gmalloc()

From: Fabrice Popineau
Subject: Re: w32/w64 Emacs and gmalloc()
Date: Sat, 1 Mar 2014 21:12:01 +0100

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:

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 :
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]