4 ms·

Emacs somewhat famously uses "unexec" in its build process, you build a skeletal Emacs in C (mostly the Emacs Lisp implementation), run it, load and compile and

by geofft 7y ago

Emacs somewhat famously uses "unexec" in its build process, you build a skeletal Emacs in C (mostly the Emacs Lisp implementation), run it, load and compile and process a bunch of Lisp that implements the editor itself, and dump the resulting process memory back out to disk. The result of this eldritch process is the final emacs binary. When you exec emacs, you get an environment that consists of the editor code ready to go.

aasasd 7y ago
squints Sooo... Elisp has AOT compilation!
lilyball 7y ago
I'm given to understand that the macOS implementation of malloc had to have special-cased code in it just to support emacs due to this approach.
- saagarjha 7y ago
  For the curious: https://opensource.apple.com/source/libmalloc/libmalloc-166.251.2/src/frozen_malloc.c.auto.html https://opensource.apple.com/source/libmalloc/libmalloc-166....
- tambourine_man 7y ago
  Why?
  - jandrese 7y ago
    Because linkers are too easy? It really looks like some overly clever college student's weird trick that somehow managed to survive for decades in an established product.
    - jws 7y ago
      It comes from a time of machines executing instructions thousands of times slower than they do now. Literally – thousands. Memory access was about as fast as an instruction execution, so the amount of compute you can justify per unit of data was hundreds of times less than it is now. They did however have virtual memory systems with on demand page fetching. Also, that machine was being time shared with a dozen or more users. Launching emacs or TeX on this machine might take tens of seconds without access to unexec(), but only 3 seconds for the freeze dried version. unexec() was easier at the time. There were no shared libraries, no address space layout randomization. One memory region grew up from the bottom, one down from the top. There was no mmap() jamming mysterious stuff in the middle. Just copy the bottom, copy the top, do magic to adjust the stack for your unexec() call, and write the thing out as an executable. (Yeah, I excised unexec() from BibTeX back in the ‘80s to port it to a 68k Mac for a coworker, then later implemented unexec() for a Motorola 88k based multilevel secure SysV system in the early ‘90s because launching emacs was driving me insane. I prefer our shiny new future of stupidly fast computers.)
shoo 7y ago
"Removing support for Emacs unexec from Glibc" -- https://lwn.net/Articles/673724/ https://lwn.net/Articles/673724/
- saagarjha 7y ago
  Interestingly, even if Emacs removes this I see Apple being forced to keep their hack in place as they're not likely to update their version of Emacs anytime soon…
trasz 7y ago
The idea is somewhat similar to Android's zygotes, isn't it?

by geofft 7y ago

aasasd 7y ago

squints Sooo... Elisp has AOT compilation!

lilyball 7y ago

I'm given to understand that the macOS implementation of malloc had to have special-cased code in it just to support emacs due to this approach.

saagarjha 7y ago
For the curious: https://opensource.apple.com/source/libmalloc/libmalloc-166.251.2/src/frozen_malloc.c.auto.html https://opensource.apple.com/source/libmalloc/libmalloc-166....
tambourine_man 7y ago
Why?
- jandrese 7y ago
  Because linkers are too easy? It really looks like some overly clever college student's weird trick that somehow managed to survive for decades in an established product.
  - jws 7y ago
    It comes from a time of machines executing instructions thousands of times slower than they do now. Literally – thousands. Memory access was about as fast as an instruction execution, so the amount of compute you can justify per unit of data was hundreds of times less than it is now. They did however have virtual memory systems with on demand page fetching. Also, that machine was being time shared with a dozen or more users. Launching emacs or TeX on this machine might take tens of seconds without access to unexec(), but only 3 seconds for the freeze dried version. unexec() was easier at the time. There were no shared libraries, no address space layout randomization. One memory region grew up from the bottom, one down from the top. There was no mmap() jamming mysterious stuff in the middle. Just copy the bottom, copy the top, do magic to adjust the stack for your unexec() call, and write the thing out as an executable. (Yeah, I excised unexec() from BibTeX back in the ‘80s to port it to a 68k Mac for a coworker, then later implemented unexec() for a Motorola 88k based multilevel secure SysV system in the early ‘90s because launching emacs was driving me insane. I prefer our shiny new future of stupidly fast computers.)

shoo 7y ago

"Removing support for Emacs unexec from Glibc" -- https://lwn.net/Articles/673724/ https://lwn.net/Articles/673724/

saagarjha 7y ago
Interestingly, even if Emacs removes this I see Apple being forced to keep their hack in place as they're not likely to update their version of Emacs anytime soon…

trasz 7y ago

The idea is somewhat similar to Android's zygotes, isn't it?