Remacs: About unexec feature

[jeandudey]

Is unexec() feature a must to have in Remacs?

I think is quite old and supporting it would be very hard because we would need to maintain the emacs malloc implementation because support for unexec is being removed from glibc.

Also there is a lot of support code for other platforms that makes the project itself more complex because it makes more easily to break things.

Disadvantages

• Remacs will load slower.
• It will take some time to find a solution to the problem of slow loading.

Advantages

• Clean code :+1:
• It makes more easy to port functions related to memory management to Rust.

[DavidDeSimone]

My personal take on this matter, is that one of the most exciting features of Rust is not having to choose between speed and safety. My fear is that by removing 'unexec' without another solution in place, the resulting slow load times will lead to the remacs project gaining a reputation for being "slower and worse performing" then mainstream emacs. Some users are likely to attribute this to the language choice itself, and potentially cause them to write off the project.

Even with these concerns, I still consider exec a long term maintainability issue for both mainline emacs and the remacs project. I think there is significant value to finding another solution to the load time problem.

[ljos]

There is a very real effort to remove the unexec from emacs mainline. There are two solutions that have been/are worked on:

1. Big .elc
2. Portable dumper

The consensus right now seem to be that they want to go for the big .elc approach, but it is dependent on them getting the loader fast enough so that startup times are not noticeably worse. It is not completely obvious that that is going to be true.

It could be possible for remacs to take the other approach and use the patches for the dumper instead, which will work and is simpler than the unexec approach. The reason this approach was voted down was that some of the maintainers felt that the code is still complicated and difficult to maintain because it is written in C.

[Wilfred]

I definitely think unexec needs to be removed eventually. It's a significant maintenance burden and source of bugs. It also makes porting harder.

I think @DavidDeSimone is right though, we shouldn't just remove it without having a replacement. My initial crude benchmarks suggest that Rust primitive functions are at least as fast as the C code they replace. It would be a shame if we had worse performance, because first impressions matter.

Without unexec the runtime performance is no worse, it just adds to startup time.

I think the portable dumper approach would be a better fit for Remacs. That approach has a patch already, and would make our code cleaner and more portable.

[JAremko]

• Vim and Emacs are two big editing tools for the "coffee machine" OSes and some of them(like Alpine Linux) are based on musl libc. It would be great if maintainers of such distros would have less headaches with building and running Remacs than Emacs.
• Also it's impossible to build Emacs in the environments like Docker without hacks https://github.com/docker/docker/issues/22801
• It may be problematic to keep unexecute and peruse one of the Remacs major goal "improving code maintainability":
• From http://emacshorrors.com/posts/unexecute.html
  > Not only is this a pretty gross and unportable hack which will probably fail on systems using memory security measures, no, it is something only a few people will fully understand, let alone be able to fix when faced with problems at this stage of the build process.

Just passing by...

[ljos]

Though it works for the most part, it seems that the work on the portable dumper has stalled; probably because of the holidays and the new year. It seems Daniel Colascione found a bug in his implementation in late December and is working on a fix, but it doesn't seem like he has found a solution yet. Which means remacs can't just take his patch and assume that it is going to work at the moment.

[nickdrozd]

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d12e5d003d503025c1c9b0335d6518a6c3bdfae1

[jaccarmac]

Now that this is a real target, I would suggest getting a commit from after the pdump patch merged. If this would truly simplify memory management it may well have significant impact on i.e. #73.

[shaleh]

I made changes recently so the unexec can be turned off for MacOS. It always could for Linux. Now the CANNOT_DUMP=yes option that has always been there actually works for remacs. So even without the upstream work you can try remacs without unexec. It is slower to load but no real change at run time.