LWN: Comments on "The Emacs dumper dispute"

The Emacs dumper dispute

nix — Thu, 08 Dec 2016 17:55:22 +0000

> This is factually incorrect: Emacs only uses its own malloc implementation during dumping. The dumped emacs executable uses the native malloc implementation on all the platforms mentioned in the previous post.

Really? Last time I tried to trace through the bugger it spotted the lack of malloc_set_state() and fell back to gmalloc for everything from dumping onwards, with fairly nasty consequences for memory usage. If the nasty consequences only relate to the relatively small amount of state stored during dumping, I'm fairly mystified as to how multi-hundred-MiB variances could be so apparent -- but Emacs is such a dynamic system that maybe I was being misled by perfectly normal run-to-run variability.

The Emacs dumper dispute

nix — Thu, 08 Dec 2016 17:53:15 +0000

Er, the entire comment directly relates to what happens when a newly-compiled Emacs starts on a new glibc (it uses its own malloc()) and/or what an Emac compiled against an older glibc does (Emacs binds to the malloc_set_state() compat symbol, the implementation of which detects the old glibc's heap format etc etc).

The Emacs dumper dispute

nix — Thu, 08 Dec 2016 17:48:51 +0000

The problem is not the interpreter. The problem is that the interpreter is tightly intertwingled into Emacs's C internals -- variables on the C stack often have alternate personae in the Lisp world and vice versa.

The problem is disentangling that such that the interpreter can be replaced, without making Emacs into even more of a maintenance nightmare than it already is.

The Emacs dumper dispute

welinder — Thu, 08 Dec 2016 14:54:50 +0000

Eli showed good technical judgment 20 years ago when I last dealt with him on a
regular basis. (And tried to hire him. Maybe it's time to try again.) If you think you
have found some basic programming thing he doesn't understand, chances are
good you overlooked something.

*My* preferred solution to the dumping issue would be to collect all the elc files
that are currently predumped and concatenate them all into one giant startup
file to-be-loaded, basically, by temacs. That's not currently fast enough, but
lexing and parsing elc files should be possible at hundreds of megabytes per
second.

The Emacs dumper dispute

lambda — Tue, 06 Dec 2016 05:49:55 +0000

As weird as it feels to suggest it, have you tried Visual Studio Code? It's free software, and it's actually a fairly decent lightweight IDE scriptable in JavaScript.

The Emacs dumper dispute

eduard.munteanu — Sun, 04 Dec 2016 22:12:34 +0000

In that case, we should agree that the real culprit is the compiler/runtime. Caching JIT/AOT compilers can and do solve the startup delay issue for other languages, and it looks like that's what's missing here.

The Emacs dumper dispute

viro — Sun, 04 Dec 2016 19:21:35 +0000

You are making several completely unwarranted assumptions:

1) that data structures won't take a lot more than the code would

2) that *all* developers can tell their arse from elbow and memory leak from decent behaviour.

Note that relatively few participants can introduce leaks faster than everybody else manages to fix them...

The Emacs dumper dispute

drag — Sun, 04 Dec 2016 18:09:39 +0000

> What if *everyone* did this?

There are a lot of benefits to this approach besides speeding up start-up.

Gnome-terminal, tmux, emacs... these are a few of the things that have this model of having a 'server'. If you want to expand the definition somewhat this is not much far off of what Chrome and Firefox browsers are following.

Seems to be a nice way to go.

The Emacs dumper dispute

mstone_ — Sun, 04 Dec 2016 17:19:01 +0000

But, who cares? The size of code on a modern system is negligible; we're buying gigabytes of RAM for data and the code size is pretty much an afterthought. It would be a shame if people focused on making it possible to free a couple of megabytes here or there instead of focusing on correctness or performance or something else with more tangible benefit.

The Emacs dumper dispute

eliz — Sun, 04 Dec 2016 09:25:53 +0000

> On those platforms, Emacs uses its own malloc() implementation, which is an ancient malloc from the early 90s

This is factually incorrect: Emacs only uses its own malloc implementation during dumping. The dumped emacs executable uses the native malloc implementation on all the platforms mentioned in the previous post.

> It should rely on the documented malloc() interface, sans ridiculous dumping hooks, and serialize for dumping. That Eli doesn't understand that this is obviously the only even vaguely maintainable approach is baffling to me.

In fact, Eli understands this simple fact very well. There's never been any question that unexec should go. The issue at hand is what is the best alternative to unexec, with all its problems.

The Emacs dumper dispute

smurf — Sat, 03 Dec 2016 08:58:35 +0000

Probably not all that much. Off the top of my head I'd schedule a full-time month to lay out the data structures required and write the code to work with them, another full-time month to cook up a working Lisp interpreter prototype, and a year (part time) to get more optimizations in and all the bugs and kinks out.

The main problem with RPython is that you don't have a dumper any more. Emacs would need to use a lot more on-demand loading, instead of packing everything and its kitchen sink into a dump image, to get initial performance up to acceptable levels.

The Emacs dumper dispute

giraffedata — Sat, 03 Dec 2016 00:35:07 +0000

I don't know what any of that has to do with the question, which was a very good one.

But I combed the article again, and see the answer:

The problem being solved by the portable dumper work is not that old Emacs won't run on new Glibc. The article starts off describing that problem, but only as an example of the effect of the larger problem:

So something clearly needs to be done to make the Emacs dumping facility more stable and, preferably, more maintainable going forward.

The article doesn't mention any solution for the Emacs 25.1-on-glibc-2.24 problem; maybe there isn't one.

The Emacs dumper dispute

kleptog — Fri, 02 Dec 2016 22:52:54 +0000

Whenever I see discussions about language compilers I think of PyPy. How much work would it be to write a Emacs LISP interpreter in RPython, because then PyPy would give you a JIT interpreter for free.

The Emacs dumper dispute

quotemstr — Fri, 02 Dec 2016 16:36:28 +0000

I also object as a matter of principle to the idea that we should forgive long startup times generally and paper over the delays by structuring every application as a client-server system. What if *everyone* did this? We'd live in a world where no program you ran would ever really leave memory. It's an incredible waste of system resources. Plus, with client-server setups, it's hard to get things like security, environment variable propagation, reliable daemon restarts, process priority, file descriptor inheritance, etc. right, and everyone who writes one of these daemon systems has to deal with these fiddly issues alone.

You could argue that dumping is also papering over performance problems, but at least dumping does so in a way that doesn't have negative global performance implications. I wish kernel-level checkpoint and restart were widely available: if the system managed the dumping instead of individual processes like Emacs having to do this work, we'd be better off.

The Emacs dumper dispute

Cyberax — Fri, 02 Dec 2016 16:07:19 +0000

Vim codebase is nowhere near Emacs' level of bogosity. It's mostly straightforward clean C.

And there are alternative projects to improve Vim. Personally, I'm donating to https://neovim.io/ - it's a very nice project. I'm planning to sponsor the development of next version of MidnightCommander based on it.

The Emacs dumper dispute

tome — Fri, 02 Dec 2016 15:56:27 +0000

One problem that vim (which I love BTW) shares with emacs is a lack of C-level internals-savvy developers. If Bram gets hit by a bus, perish the thought, it will be a long time before vim development again progresses at its current speed, which is already slower than emac'es.

The Emacs dumper dispute

rsidd — Fri, 02 Dec 2016 14:09:03 +0000

Thanks for the explanation. Looks like things would have been better all around if Emacs had adopted the same strategy on linux and let glibc do its thing separately! But both of them being GNU projects complicates things :(

The Emacs dumper dispute

nix — Fri, 02 Dec 2016 12:25:04 +0000

The server is decades newer than the dumper. Plus, the server was distinctly unreliable until a relatively short number of decades ago, and you still have to wait for emacs --daemon to start now and then. (Though, frankly, mine takes ten minutes to start anyway because I have so many buffers open... a 10s delay to load Lisp as well would be totally ignorable to me, but not to everyone, and most certainly not to the byte-compilation phase of Emacs building, which starts Emacs hundreds of times.)

The Emacs dumper dispute

nix — Fri, 02 Dec 2016 12:23:34 +0000

On those platforms, Emacs uses its own malloc() implementation, which is an ancient malloc from the early 90s and is notably less efficient than glibc's malloc() (which is itself not as good as modern malloc()s, but which has been unable to improve because almost any change would break previously-dumped Emacsen: hence all this mess).

(Needless to say, Emacs should not be providing its own not-terribly-good malloc() implementation. It should rely on the documented malloc() interface, sans ridiculous dumping hooks, and serialize for dumping. That Eli doesn't understand that this is obviously the only even vaguely maintainable approach is baffling to me.)

The Emacs dumper dispute

zblaxell — Fri, 02 Dec 2016 03:48:41 +0000

Odd, I thought the point of using a museum piece as a text editor was to get the vintage green-scrolling-text-at-19200-baud feel without the decade-later vintage NCD-xterm-flickering-display-update horror. If you wanted smooth horizontal scrolling, why were you using Emacs?

Seriously, though, in the world outside of Emacs it would be much easier to have the elisp thread ping the render thread to say "ok now is/is not a good time to take your screenshot away for rendering" than to try to get a single thread to run elisp, push updates at the display refresh rate, and avoid burning resources on unnecessary rendering. The original Emacs design assumed those things would be done on a dedicated external processor, not embedded in the REP loop.

Apart from anything else it's a waste of CPU cores to only use one. The rendering task takes a few milliseconds, and waiting for rendering will burn time Emacs could be spending on deciding what to display next.

The Emacs dumper dispute

da4089 — Fri, 02 Dec 2016 02:22:13 +0000

If Emacs were to grow its own libc implementation, that would solve not only this problem, but potentially others in future as well!

The Emacs dumper dispute

eduard.munteanu — Thu, 01 Dec 2016 22:06:30 +0000

Odd. I thought Emacs had a server mode which allowed thin clients to be spawned quickly when invoked. Why the dumper? Doesn't the server cater for startup delay issues?

The Emacs dumper dispute

SEMW — Thu, 01 Dec 2016 10:17:12 +0000

For what it's worth, Vim has been accruing plugin bindings for various languages for a while; it now supports ruby, python2, python3, perl, lua, and tcl plugins.

The Emacs dumper dispute

smurf — Thu, 01 Dec 2016 07:17:57 +0000

Because Emacs is a complex beast which frequently requires more that .02 seconds to render a complex buffer, and you don't want a half-written frame to show up on your screen. Ever.

Suppose you do horizontal scrolling. You don't want the top part of your buffer to be to the right of the bottom part. Not even for 1/60th of a second.

Yes, power users care about that sort of thing. Yes, it can be noticeable, even at that speed.

The Emacs dumper dispute

felixfix — Thu, 01 Dec 2016 07:07:51 +0000

Thanks. A very useful and entertaining link.

The Emacs dumper dispute

rsidd — Thu, 01 Dec 2016 06:50:58 +0000

I'm extremely ignorant of this stuff, but if emacs depends on these low-level glibc hooks for loading the dumped image, how does it work on other platforms (OS X, Windows, the BSDs, various proprietary Unixes, etc?)

The Emacs dumper dispute

drag — Thu, 01 Dec 2016 06:12:38 +0000

you referencing https://atom.io/ ?

Emacs double buffering

AdamW — Thu, 01 Dec 2016 06:03:29 +0000

"There are often times when I'm amazed that anything we use actually works"

This is how I feel literally all the time.

The Emacs dumper dispute

quotemstr — Thu, 01 Dec 2016 04:55:31 +0000

What about JavaScript?

The Emacs dumper dispute

zblaxell — Thu, 01 Dec 2016 04:55:11 +0000

I am completely mystified about why the second half of the article isn't

"...so we spawn a second thread in main() which emulates exactly the terminal IO model Emacs was designed for. Every 16.7ms, this thread takes a snapshot of what Emacs has written on its frames so far, renders the text in a backbuffer, and swaps buffers with the display frontbuffer (unless the frames haven't changed and we don't have any Expose events to deal with). Emacs updates its frames whenever the hell it wants and nobody bothers Emacs to do anything it doesn't want to. Then we walked through all the #ifdef five-toolkits mess and just deleted it. You're welcome."

In this century we have smartphones that can render a screen full of text faster than the monitor refresh rate while digitally emulating in real time the electron-beam distortions that text would encounter as it passes through the analog electronics of a vintage 1980's CRT. It sounds like this Emacs hack is solving the problem the Emacs way instead of the sane way.

I suspect the solution to the mystery is going to be another level of mystery (I think the first level of that might be "OK so threads and unexec don't get along well, but why did anyone think unexec was the best of several potential alternative solutions, even at the time?"), recursively descending until one of us shouts "you people are crazy" and storms out of the room.

the sort of thing that could give vi a definitive advantage in the interminable editor wars

This is a serious misunderstanding of the editor wars. The alternative is not the other editor. The alternative is downgrading glibc.

The Emacs dumper dispute

karim — Thu, 01 Dec 2016 04:52:55 +0000

I don't have any specific language in mind, but at least something more like the semantics of more mainstream languages such as C, Java, and so on. I've programmed in Lisp in the past but it has very peculiar semantics which make it very heavy and require switching into a different mindset. At least if it was something a more "mainstream", I could more easily parse/tweak/extend my own editor.

The Emacs dumper dispute

quotemstr — Thu, 01 Dec 2016 04:47:19 +0000

What language would you prefer to use for extending your editor? Alternatives may arrive sooner than you expect.

The Emacs dumper dispute

karim — Thu, 01 Dec 2016 04:36:43 +0000

I've used emacs for 20+ years now as my main editor. And, frankly, I never really got into its lisp ways. In fact, I've always found its reliance on Lisp to be an impediment to my use of it. At this point I've been shopping around for a replacement for about 2 or some years now, with nothing really good enough yet (or just not enough time to fairly evaluate some of the replacements in full.) So reading this just makes me think that I should spend some more time on those alternatives ...

The Emacs dumper dispute

nix — Thu, 01 Dec 2016 00:03:38 +0000

Quite. What's more, we already *have* most of this sort of chase-everything machinery in place for the garbage collector, and we can serialize most types thanks to print-forms. This form of it *is* somewhat different because of the relocation/pointer-fixup stuff, but it's not really difficult stuff, just deeply fiddly, and is by any measure drastically less horrifying than the tar pit of crawling horrors that is unexec(). It's also what almost every other Lisp implementation in existence does (back in the era of my parents' parents' parents, they all used unexec()-like tricks too, but nothing still in use does, as far as I know: they've all moved to serialization or their own allocators with built-in dumping/serialization long ago; nothing else depends on special support from libc's malloc like Emacs does. Emacs is literally decades behind the times here.)

Also, anything that makes Emacs more portable is good in my book, and unexec() was a major impediment to Emacs porting. Congratulations, Daniel!

The Emacs dumper dispute

nix — Wed, 30 Nov 2016 23:58:59 +0000

When the malloc_get/set_state() functions are not available, Emacs falls back to a built-in malloc(), which is slower and less efficient than glibc malloc(), but works (or was believed to until this ralloc() issue turns up). malloc_set_state() -- used when loading a previously-dumped Emacs -- *still exists* in newer glibc, but as a compat symbol that cannot be linked against: glibc will detect when the old heap format is used by something calling malloc_set_state() (i.e., by an Emacs linked against an older glibc) and will mark the old heap dynamically as something allocated but unfreeable, which is good enough to work with a newer glibc no matter what its malloc implementation (but unlike in older glibc, the dumped heap remains a separate arena which the new malloc() is ignorant of, so free()ing from it does nothing, and new malloc()s will never come out of that arena). However, newly-compiled Emacsen will obviously not get a heap format compatible with this scheme, so malloc_get_state() is not available even as a compat symbol (or, rather, it is, because Emacs still has an undefined symbol referring to it, but its implementation has been stubbed out and always returns -ENOSYS).

I'll have to catch up with the emacs dev list, clearly -- I had no idea about this latest ralloc mess, though it was probably predictable because next to nothing has used ralloc for years so it has probably bitrotted catastrophically.

Emacs double buffering

corbet — Wed, 30 Nov 2016 23:14:00 +0000

Indeed worth a read. There are often times when I'm amazed that anything we use actually works; this is one of them.

Wish I'd seen it when it was fresh, it would have been great QOTW material.

The Emacs dumper dispute

louie — Wed, 30 Nov 2016 22:16:28 +0000

That was an amazing read. Thanks for posting it.

The Emacs dumper dispute

kfogel — Wed, 30 Nov 2016 21:28:06 +0000

For anyone who wants a better understanding of the potential security vulnerability under discussion, this post today from Daniel Colascione explains it in a clear and simple way:

https://lists.gnu.org/archive/html/emacs-devel/2016-11/ms...

From: Daniel Colascione
Subject: Re: Preview: portable dumper
To: Emacs Devel
Date: Wed, 30 Nov 2016 12:18:21 -0800
Message-ID: <r0251sxsoh6a.fsf@dancol.org>

The Emacs dumper dispute

vadim — Wed, 30 Nov 2016 19:43:40 +0000

I don't see the concern about turning off developers -- it seems to be at the same or better level as what there is already.

I haven't worked on the Emacs code, but if I was going to be turned off by something, it would be by some weird black magic that relies on the obscure innards of the implementation of malloc(), and not on a mechanism that serializes data. Walking a data structure and dumping stuff to disk is standard C fare. It might be a complicated instance of it, but unlike something that digs around in the innards of malloc it would be something I could expect to reasonably understand given a normal amount of time and effort. Not so with the unexec stuff.

Besides, we're talking about what amounts to an optimization. If I was going to start working on Emacs now, I don't see myself getting scared off by what is effectively a completely optional piece of code.

The Emacs dumper dispute

jlargentaye — Wed, 30 Nov 2016 19:15:27 +0000

> It is not entirely clear, though, that C programmers are actually a dying breed — or that the long-term supply of Elisp developers is more certain.

Speaking of which, how's Guile-Emacs doing?...