What are the constraints/limitations of compiling with "+native" ?

Question

What are the limitations/constraints when compiling Erlang .erl source with the +native option compared with the usual "non native" compilation?

Related to: http://stackoverflow.com/questions/2207360/erlang-otp-release-compiles-with-hipe

Answer 1

The functionality for tracing, breakpoints and single stepping that the BEAM emulator provides are not available in native compiled code. There is also still a limitation that native code is not really unloaded from memory when you load newer versions of the same module. (This can be an issue if you have a long-running system where you keep upgrading modules or generate and compile modules dynamically.)

Furthermore, there is a small overhead when jumping between native code and emulated BEAM code, so you should avoid having that kind of mode switch in a tight loop where speed matters. Preferably compile all closely related modules to native, and if possible also the most important standard library modules.

Finally, although the native compiler is quite well tested, the probability of a compiler bug in HiPE is a bit higher than that of bugs in the BEAM emulator C code (though probably no higher than that of bugs in GCC), so you may run a greater risk of system segfaults. It's quite rare these days though.

In summary, the main place where native compilation is probably not recommended for now, is in stand-alone products (like a black-box server that you deliver to a customer), where stability, remote debuggability, and low memory usage are your main concern and computation speed is typically not.