How the BEAM boots and what can be done about it
TALK LEVEL: BEGINNER / INTERMEDIATE / ADVANCED
The Erlang VM does a lot of work loading and transforming many little BEAM files before it is ready to go. When starting Elixir even more beam files have to be loaded. Doing this work over and over again leads to unfavourable startup time. Most clearly this shows on embedded systems with weak CPUs, inefficient files systems and storage and no way to cache the filesystem when switched on. But this extra work also shows up everywhere the Erlang VM is started again and again, e.g. during development and in CI/CD systems.
In this talk, we explore what exactly is done by the BEAM loader and how we can move this work to release build time so it doesn't have to be done again and again on startup.
Transforming all the little BEAM files into normal object files a static or dynamic linker can use and relocate gives us several benefits at the same time:
- Ready to run in place beam code - reduced startup time
- Faster cloud spin uptime with standard Erlang VMs
- Single executable releases - wouldn't it be nice to deploy just a single-file executable that contains the Erlang VM and the complete relates BEAM files?
- Deploy complete Erlang releases on System on Chip Micro-Controllers by running everything directly in firmware flash
In this talk, you will get a clear explanation of how all this works and demos of the implementation.
THIS TALK IN THREE WORDS
Fast
BEAM
Start
OBJECTIVES
- Learn what happens during code loading in BEAM
- Learn about ELF object files and relocation
- Understand how beam files can be preloaded to run in place
TARGET AUDIENCE
- People who want to learn about the inner workings of the BEAM
- People who are interested in startup time speedup
- People who care about single executable release+VM deployment
