[Top][All Lists]

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

Re: size of emacs executable after unicode merge

From: Stefan Monnier
Subject: Re: size of emacs executable after unicode merge
Date: Fri, 31 Oct 2008 12:44:29 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

> To allow the allocator can release pages back to the system after they
> being garbage collected, you have to be sure that absolutely ALL the
> data allocated can be garbage collected.   (and even then you depend on
> the quirks of the platform specific malloc implementation to do it).

Indeed.  Some malloc implementation just never return memory to the
system, and all others only do it in some cases but not all.  And in our
case we may not even be able to call `free' because some live data is
interspersed within the sea of dead data.

> So it sounds that your goal is to build Vchar_unify_table, and it is
> build from static data in emacs/etc/charsets/*.  In that case, can't the
> data in Vchar_unify_table be a C data structure that is build offline,
> and just compiled into emacs?

Maybe simpler would be to build this table as we do now, then print it
into a file.  Then the "dump" doesn't need to build the table, it can
just read it from the file.


reply via email to

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