问题
When I start up my Erlang emulator, there the first bit has a bunch of informational things. (Slightly reformatted for effect.)
manoa:~ stu$ erl
Erlang (BEAM) emulator version 5.6.5
[source] [smp:2] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
1>
Some of it I can guess at, probably accurate, but some of it means 'here be magic'.
Erlang (BEAM) emulator version 5.6.5: the version, of course[source]: the emulator was compiled from source?[smp:2]: two CPU cores detected and available[async-threads:0]:currently running jobs?[hipe]: ?[kernel-poll:false]: ?
I also wonder if there are other [foo] items that may pop up with different configurations, builds or start up parameters.
So, what do the Erlang emulator info statements mean?
回答1:
[async-threads:0]
Size of async thread pool available for loaded drivers to use. This allows blocking syscalls to be performed in a separate kernel thread from the beam vm. Use command switch +A N to adjust the size of the pool.
[hipe]
Support for native compilation of erlang source and bytecode. Tends to mostly be useful for number crunching code. IO-bound code do fine on the bytecode interpreter.
[kernel-poll:false]
There is the old select(2) and poll(2) system calls for receiving notification that some file descriptor is ready for unblocking writing or reading. They do not scale well to high number of open file descriptors. Modern operatingsystems have alternative interfaces, linux has epoll, freebsd has kqueue. Enable with command switch +K true
回答2:
As of Erlang 20.0, the full set of version string tags is:
[64-bit]
The BEAM emulator is built to make full use of a 64-bit CPU.
[async-threads:10]
This refers to the number of threads in the Erlang emulator's async thread pool, which more or less tells you how many blocked system calls can be spun off into background threads before the emulator stalls.
Though it currently defaults to 10, the default was 0 for many years, which meant that all system calls were run synchronously within each Erlang emulator thread. When a system call blocked, it stopped that Erlang emulator thread from running until the system call finished. The current small default value allows the emulator to try to go off and do something else while a system call is blocking one of the async I/O threads.
You can change the default value with the +A option to the Erlang runtime. (e.g. erl +A 50) If you are going to change this, beware that your results will depend on your particular system and workload. Too high a value could hurt performance, because it causes the system to try doing many things in the background when the system is very busy, which only makes it even more busy. On some workloads, disabling the feature with erl +A 0 could be the best option.
[debug-compiled]
This only appears if you go out of your way to build an alternate BEAM emulator with the compiler options set to make the resulting executable easier to debug, as with gdb or similar. You also have to run this alternate BEAM emulator in a special way.
The Erlang BEAM emulator is normally built for speed, which often makes a debugger's job harder. If you are working on the development of the next version of the BEAM emulator, you may find it helpful to run special debug builds of it as you refine your work.
To enable this mode, cd into erts/emulator under the Erlang source tree after you have run configure on it, then type something like ERL_TOP=../.. make FLAVOR=smp debug. Then to run your new debuggable BEAM emulator, you have to run bin/cerl -debug from the top level of the Erlang source tree, after the rest of the Erlang/OTP system has been built.
See How to Build a Debug Enabled Erlang RunTime System for more on this topic.
[ds:1:1:1]
As of ERTS 9.0, this should always appear if you built the BEAM emulator with SMP support. It refers to the "dirty schedulers" feature. The values describe the feature's configuration on this system.
This feature was introduced with Erlang 19.0, initially as an experimental feature that wasn't compiled in by default in SMP builds as it is in Erlang 20.0.
[dtrace]
Appears if you passed --with-dynamic-trace=dtrace to the configure script to enable the experimental DTrace instrumentation feature added in R15B01. This feature is only expected to work on OS X, Solaris and FreeBSD. It may work on other platforms in the future. See [systemtap] below for an alternative added at the same time for Linux systems.
[frame-pointer]
This is a special case of the [debug-compiled] option above, except that it only disables the frame pointer optimization. Use frmptr instead of debug in the commands above to enable this mode.
[hipe]
The emulator was compiled with the HiPE feature enabled, which is an on-the-fly native code compiler for Erlang. It only works on the most popular CPU types that Erlang supports, and it doesn't work with all configurations even on those CPUs, which is why it's optional.
[instruction-counting]
Appears if you define ERTS_OPCODE_COUNTER_SUPPORT during the build, which enables a BEAM opcode counting feature, presumably useful to those profiling BEAM emulator performance.
[kernel-poll:false]
The Erlang emulator code knows several different ways to ask the OS's network stack which of a set of file descriptors and sockets are available for I/O. The only one that works pretty much everywhere is the old BSD select() call which is relatively slow due to its design, and has other scalability issues besides. So, most systems have one or more faster and more scalable replacements — e.g., kqueue, epoll(), etc. — but none of them is supported everywhere. When the emulator startup message says false here, it can mean either that kernel polling isn't available or that it is but you did not pass +K true to erl.
[lock-checking]
Appears if you passed --enable-lock-check to the configure script.
[lock-counting]
Appears if you passed --enable-lock-counter to the configure script.
[lttng]
Appears if you passed --with-dynamic-trace=lttng to the configure script to enable support for LTTNG, a tracing framework for Linux.
[purify-compiled]
This appears when you run a special Purify-aware version of the Erlang BEAM emulator.
The instructions are the same as in the [debug-compiled] section above, except that you use purify in commands instead of debug.
[sharing-preserving]
This appears if you pass --enable-sharing-preserving to the configure script, which causes to share immutable terms intra-node instead of flattening and recreating them. Whether this option makes your program faster or slower depends on details of the program, hence why it is not set in the default build.
[smp:2:2]
The [smp:2] tag changed to this format in Erlang R13, meaning 2 schedulers, both of which are online. If you say "erl +S1", it says [smp:1:1] instead. You can take schedulers offline at runtime with erlang:system_flag(schedulers_online, N), where N can be anything between 1 and the number of cores detected, inclusive.
[source] or [source-VERSION]
It means some third party (maybe you, maybe your OS distro's package maintainer, maybe your sysadmin) built Erlang from source code. The alternative is downloading an official binary version from Erlang.org.
If you build Erlang from the Git repository, this message changes to something like [source-8acc644], where the hex number is a fragment of the repository's current Git hash, which allows you to check out the exact version of the source that built a given executable.
[systemtap]
Appears if you passed --with-dynamic-trace=systemtap to the configure script. This is an alternative to the =dtrace value for this configuration option, providing essentially the same functionality on Linux using SystemTap, since DTrace is not normally available on Linux. See [dtrace] above.
[type-assertions]
Appears when you uncomment the ET_DEBUG line in erts/emulator/beam/erl_term.h, enabling runtime checking of all type-specific data accesses. Not enabled by default because it slows down the emulator.
[valgrind-compiled]
This appears when you run a special Valgrind-aware version of the Erlang BEAM emulator.
The instructions are the same as in the [debug-compiled] section above, except that you use valgrind in commands instead of debug.
(This list comes from erts/emulator/beam/erl_bif_info.c in the Erlang OTP source tree. See the definition of erts_system_version near the top of the file.)
Obsolete tags:
The [64-bit halfword] optimization to 64-bit builds of the BEAM emulator was added in R14, then removed without explanation in 19.0. This also removes the possibility to see the [no-c-stack-objects] tag, which was associated with the halfword emulator.
The [rq:2] tag referred to a run queue system intended to improve scalability in SMP builds of the Erlang BEAM emulator. Added in R13B, it was replaced in R15B by a better solution.
The [hybrid-heap] and [incremental GC] tags and associated features were removed in R15B02 essentially because they were failed experiements.
来源：https://stackoverflow.com/questions/1182025/what-do-the-erlang-emulator-info-statements-mean