Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
erl(1)				 User Commands				erl(1)

NAME
       erl - The Erlang	emulator.

DESCRIPTION
       The erl program starts an Erlang	runtime	system.	The exact details (for
       example,	whether	erl is a script	or a program and which other  programs
       it calls) are system-dependent.

       Windows users probably want to use the werl program instead, which runs
       in its own window with scrollbars and  supports	command-line  editing.
       The  erl	 program on Windows provides no	line editing in	its shell, and
       on Windows 95 there is no way to	scroll back to text that has  scrolled
       off  the	screen.	The erl	program	must be	used, however, in pipelines or
       if you want to redirect standard	input or output.

   Note:
       As from ERTS 5.9	(Erlang/OTP R15B) the runtime system does  by  default
       not  bind  schedulers  to logical processors. For more information, see
       system flag +sbt.

EXPORTS
       erl <arguments>

	      Starts an	Erlang runtime system.

	      The arguments can	be divided into	 emulator  flags,  flags,  and
	      plain arguments:

		* Any  argument	starting with character	+ is interpreted as an
		  emulator flag.

		  As indicated by the name, emulator flags control the	behav-
		  ior of the emulator.

		* Any  argument	 starting  with	character - (hyphen) is	inter-
		  preted as a flag, which is to	be passed to the  Erlang  part
		  of  the runtime system, more specifically to the init	system
		  process, see init(3).

		  The init process itself interprets some of these flags,  the
		  init	flags.	It  also  stores any remaining flags, the user
		  flags. The latter can	be retrieved by	calling	init:get_argu-
		  ment/1.

		  A  small  number  of "-" flags exist,	which now actually are
		  emulator flags, see the description below.

		* Plain	arguments are not interpreted in  any  way.  They  are
		  also	stored	by  the	 init  process and can be retrieved by
		  calling init:get_plain_arguments/0. Plain arguments can  oc-
		  cur  before  the  first  flag, or after a -- flag. Also, the
		  -extra flag causes everything	that follows to	 become	 plain
		  arguments.

	      Examples:

	      %	erl +W w -sname	arnie +R 9 -s my_init -extra +bertie
	      (arnie@host)1> init:get_argument(sname).
	      {ok,[["arnie"]]}
	      (arnie@host)2> init:get_plain_arguments().
	      ["+bertie"]

	      Here  +W	w  and	+R 9 are emulator flags. -s my_init is an init
	      flag, interpreted	by init. -sname	arnie is a user	 flag,	stored
	      by init. It is read by Kernel and	causes the Erlang runtime sys-
	      tem to become  distributed.  Finally,  everything	 after	-extra
	      (that is,	+bertie) is considered as plain	arguments.

	      %	erl -myflag 1
	      1> init:get_argument(myflag).
	      {ok,[["1"]]}
	      2> init:get_plain_arguments().
	      []

	      Here the user flag -myflag 1 is passed to	and stored by the init
	      process. It is a user-defined  flag,  presumably	used  by  some
	      user-defined application.

FLAGS
       In the following	list, init flags are marked "(init flag)". Unless oth-
       erwise specified, all other flags are user flags, for which the	values
       can  be	retrieved by calling init:get_argument/1. Notice that the list
       of user flags is	not exhaustive,	there can be more application-specific
       flags that instead are described	in the corresponding application docu-
       mentation.

	 -- (init flag):
	   Everything following	-- up to the next flag	(-flag	or  +flag)  is
	   considered	plain	arguments   and	  can	be   retrieved	 using
	   init:get_plain_arguments/0.

	 -Application Par Val:
	   Sets	the application	configuration parameter	Par to the  value  Val
	   for the application Application; see	app(4) and application(3).

	 -args_file FileName:
	   Command-line	 arguments  are	read from the file FileName. The argu-
	   ments read from the file replace flag '-args_file FileName' on  the
	   resulting command line.

	   The	file  FileName is to be	a plain	text file and can contain com-
	   ments and command-line arguments. A comment begins with a # charac-
	   ter	and  continues until the next end of line character. Backslash
	   (\\)	is used	as quoting character. All command-line	arguments  ac-
	   cepted  by erl are allowed, also flag -args_file FileName. Be care-
	   ful not to cause circular  dependencies  between  files  containing
	   flag	-args_file, though.

	   The	flag  -extra  is treated in special way. Its scope ends	at the
	   end of the file. Arguments following	an -extra flag	are  moved  on
	   the	command	 line into the -extra section, that is,	the end	of the
	   command line	following after	an -extra flag.

	 -async_shell_start:
	   The initial Erlang shell does not read user input until the	system
	   boot	 procedure has been completed (Erlang/OTP 5.4 and later). This
	   flag	disables the start synchronization feature and lets the	 shell
	   start in parallel with the rest of the system.

	 -boot File:
	   Specifies  the  name	 of the	boot file, File.boot, which is used to
	   start the system; see init(3). Unless  File	contains  an  absolute
	   path,  the  system  searches	 for  File.boot	 in  the  current  and
	   $ROOT/bin directories.

	   Defaults to $ROOT/bin/start.boot.

	 -boot_var Var Dir:
	   If the boot script contains a path variable Var other  than	$ROOT,
	   this	 variable  is  expanded	to Dir.	Used when applications are in-
	   stalled   in	  another   directory	than   $ROOT/lib;   see	  sys-
	   tools:make_script/1,2 in SASL.

	 -code_path_cache:
	   Enables the code path cache of the code server; see code(3).

	 -compile Mod1 Mod2 ...:
	   Compiles  the  specified modules and	then terminates	(with non-zero
	   exit	code if	the compilation	of some	file did not succeed). Implies
	   -noinput.

	   Not recommended; use	erlc instead.

	 -config Config	[Config	...]:
	   Specifies  the name of one or more configuration files, Config.con-
	   fig,	which is used to configure applications; see app(4) and	appli-
	   cation(3).  See the documentation for the configuration file	format
	   for a description of	the configuration  format  and	the  order  in
	   which configuration parameters are read.

	 -configfd FD [FD ...]:
	   Specifies the name of one or	more file descriptors (called configu-
	   ration file descriptors from	here on) with configuration  data  for
	   applications;  see app(4) and application(3). See the documentation
	   for the configuration file format for a description of the configu-
	   ration  format  and the order in which configuration	parameters are
	   read.

	   A configuration file	descriptor will	be read	until its end and will
	   then	be closed.

	   The content of a configuration file descriptor is stored so that it
	   can be reused when init:restart/0 or	init:restart/1 is called.

	   The parameter -configfd 0 implies -noinput.

     Note:
	 It is not recommended to use file descriptors	1  (standard  output),
	 and 2 (standard error)	together with -configfd	as these file descrip-
	 tors are typically used to print information to the console the  pro-
	 gram is running in.

	   Examples (Unix shell):

	 $ erl \ -noshell \ -configfd 3	\ -eval	\ 'io:format("~p~n",[application:get_env(kernel, logger_level)]),erlang:halt()'	3< \ <(echo '[{kernel, [{logger_level, warning}]}].')
	 {ok,warning}

	 $ echo	'[{kernel, [{logger_level, warning}]}].' > test1.config
	 $ echo	'[{kernel, [{logger_level, error}]}].' > test2.config
	 $ erl \ -noshell \ -configfd 3	\ -configfd 4 \	-eval \	'io:format("~p~n",[application:get_env(kernel, logger_level)]),erlang:halt()' \	3< test1.config	4< test2.config
	 {ok,error}

	 -connect_all false:
	   If this flag	is present, global does	not maintain a fully connected
	   network of distributed Erlang nodes,	and then global	name registra-
	   tion	cannot be used;	see global(3).

	 -cookie Cookie:
	   Obsolete  flag  without any effect and common misspelling for -set-
	   cookie. Use -setcookie instead.

	 -detached:
	   Starts the Erlang runtime system detached from the system  console.
	   Useful  for	running	 daemons  and  backgrounds  processes. Implies
	   -noinput.

	 -emu_args:
	   Useful for debugging. Prints	the arguments sent to the emulator.

	 -emu_flavor emu|jit|smp:
	   Start an emulator of	a different flavor. Normally only  one	flavor
	   is  available,  more	can be added by	building specific flavors. The
	   currently available flavors are: emu	and jit. The smp flavor	is  an
	   alias  for  the  current  default flavor. You can combine this flag
	   with	--emu_type. You	can get	the current flavor at  run-time	 using
	   erlang:system_info(emu_flavor). (The	emulator with this flavor must
	   be built. You can build  a  specific	 flavor	 by  doing  make  FLA-
	   VOR=$FLAVOR in the Erlang/OTP source	repository.)

	 -emu_type Type:
	   Start  an  emulator	of a different type. For example, to start the
	   lock-counter	emulator, use -emu_type	lcnt. You can get the  current
	   type	 at run-time using erlang:system_info(build_type). (The	emula-
	   tor of this type must already be built. Use	the  configure	option
	   --enable-lock-counter to build the lock-counter emulator.)

	 -env Variable Value:
	   Sets	 the  host OS environment variable Variable to the value Value
	   for the Erlang runtime system. Example:

	 % erl -env DISPLAY gin:0

	   In this example, an Erlang runtime system is	started	with  environ-
	   ment	variable DISPLAY set to	gin:0.

	 -epmd_module Module (init flag):
	   Configures  the module responsible to communicate to	epmd. Defaults
	   to erl_epmd.

	 -erl_epmd_port	Port (init flag):
	   Configures the port used by erl_epmd	to listen for  connection  and
	   connect  to other nodes. See	erl_epmd for more details. Defaults to
	   0.

	 -eval Expr (init flag):
	   Makes init evaluate the expression Expr; see	init(3).

	 -extra	(init flag):
	   Everything following	-extra is considered plain arguments  and  can
	   be retrieved	using init:get_plain_arguments/0.

	 -heart:
	   Starts  heartbeat  monitoring  of  the  Erlang  runtime system; see
	   heart(3).

	 -hidden:
	   Starts the Erlang runtime system as a hidden	node, if it is run  as
	   a  distributed  node.  Hidden nodes always establish	hidden connec-
	   tions to all	other nodes except for nodes in	the same global	group.
	   Hidden connections are not published	on any of the connected	nodes,
	   that	is, none of the	connected nodes	are part of  the  result  from
	   nodes/0   on	 the  other  node.  See	 also  hidden  global  groups;
	   global_group(3).

	 -hosts	Hosts:
	   Specifies the IP addresses for  the	hosts  on  which  Erlang  boot
	   servers are running,	see erl_boot_server(3).	This flag is mandatory
	   if flag -loader inet	is present.

	   The IP addresses must be specified in the standard form (four deci-
	   mal	numbers	 separated  by	periods, for example, "150.236.20.74".
	   Hosts names are not acceptable, but a broadcast address (preferably
	   limited to the local	network) is.

	 -id Id:
	   Specifies  the  identity of the Erlang runtime system. If it	is run
	   as a	distributed node, Id must be identical to  the	name  supplied
	   together with flag -sname or	-name.

	 -init_debug:
	   Makes init write some debug information while interpreting the boot
	   script.

	 -instr	(emulator flag):
	   Selects an instrumented Erlang runtime system (virtual machine)  to
	   run,	instead	of the ordinary	one. When running an instrumented run-
	   time	system,	some resource usage data can be	obtained and  analyzed
	   using  the instrument module. Functionally, it behaves exactly like
	   an ordinary Erlang runtime system.

	 -loader Loader:
	   Specifies the method	used by	erl_prim_loader	to load	Erlang modules
	   into	 the  system;  see  erl_prim_loader(3).	Two Loader methods are
	   supported:

	   * efile, which means	use the	local file system,  this  is  the  de-
	     fault.

	   * inet, which means use a boot server on another machine. The flags
	     -id, -hosts and -setcookie	must also be specified.

	   If Loader is	something else,	the user-supplied Loader port  program
	   is started.

	 -make:
	   Makes  the  Erlang  runtime system invoke make:all()	in the current
	   working directory and then terminate; see make(3).  Implies	-noin-
	   put.

	 -man Module:
	   Displays  the  manual  page for the Erlang module Module. Only sup-
	   ported on Unix.

	 -mode interactive | embedded:
	   Modules are auto loaded when	they are first referenced if the  run-
	   time	 system	runs in	interactive mode, which	is the default.	In em-
	   bedded mode modules are not auto loaded. The	latter is  recommended
	   when	 the  boot script preloads all modules,	as conventionally hap-
	   pens	in OTP releases. See code(3).

	 -name Name:
	   Makes the Erlang runtime system into	a distributed node. This  flag
	   invokes all network servers necessary for a node to become distrib-
	   uted; see net_kernel(3). It is also ensured that epmd runs  on  the
	   current  host  before  Erlang  is  started;	see  epmd(1)  and  the
	   -start_epmd option.

	   The node name will be Name@Host, where Host is the fully  qualified
	   host	name of	the current host. For short names, use flag -sname in-
	   stead.

	   If Name is set to undefined the node	will be	started	in  a  special
	   mode	optimized to be	the temporary client of	another	node. When en-
	   abled the node will request a dynamic node name from	the first node
	   it  connects	 to.  In  addition these distribution settings will be
	   set:

	 -dist_listen false -hidden -dist_auto_connect never

	   Because -dist_auto_connect is set to	never, the system will have to
	   manually  call net_kernel:connect_node/1 in order to	start the dis-
	   tribution. If the distribution channel is closed, when a node  uses
	   a  dynamic node name, the node will stop the	distribution and a new
	   call	to net_kernel:connect_node/1 has to be	made.  Note  that  the
	   node	name may change	if the distribution is dropped and then	set up
	   again.

     Note:
	 The dynamic node name feature is supported from OTP 23. Both the tem-
	 porary	 client	 node and the first connected peer node	(supplying the
	 dynamic node name) must be at least OTP 23 for	it to work.

     Warning:
	 Starting a  distributed  node	without	 also  specifying  -proto_dist
	 inet_tls  will	 expose	the node to attacks that may give the attacker
	 complete access to the	node and in extension the cluster. When	 using
	 un-secure distributed nodes, make sure	that the network is configured
	 to keep potential attackers out.

	 -no_epmd:
	   Specifies that the distributed node does not	need epmd at all.

	   This	option ensures that the	Erlang runtime system does  not	 start
	   epmd	 and  does not start the erl_epmd process for distribution ei-
	   ther.

	   This	option only works if Erlang is started as a  distributed  node
	   with	 the  -proto_dist option using an alternative protocol for Er-
	   lang	distribution which does	not rely on epmd for node registration
	   and discovery. For more information,	see How	to implement an	Alter-
	   native Carrier for the Erlang Distribution.

	 -noinput:
	   Ensures that	the Erlang runtime system never	tries to read any  in-
	   put.	Implies	-noshell.

	 -noshell:
	   Starts  an  Erlang runtime system with no shell. This flag makes it
	   possible to have the	Erlang runtime system as a component in	a  se-
	   ries	of Unix	pipes.

	 -nostick:
	   Disables  the  sticky directory facility of the Erlang code server;
	   see code(3).

	 -oldshell:
	   Invokes the old Erlang shell	from Erlang/OTP	3.3. The old shell can
	   still be used.

	 -pa Dir1 Dir2 ...:
	   Adds	 the  specified	directories to the beginning of	the code path,
	   similar to code:add_pathsa/1. Note that the order of	the given  di-
	   rectories will be reversed in the resulting path.

	   As  an  alternative	to  -pa,  if  several  directories  are	 to be
	   prepended to	the code path and the directories have a common	parent
	   directory,  that  parent  directory can be specified	in environment
	   variable ERL_LIBS; see code(3).

	 -pz Dir1 Dir2 ...:
	   Adds	the specified directories to the end of	the code path, similar
	   to code:add_pathsz/1; see code(3).

	 -path Dir1 Dir2 ...:
	   Replaces the	path specified in the boot script; see script(4).

	 -proto_dist Proto:

	   Specifies a protocol	for Erlang distribution:

	   inet_tcp:
	     TCP over IPv4 (the	default)

	   inet_tls:
	     Distribution  over	TLS/SSL, See the  Using	SSL for	Erlang Distri-
	     bution User's Guide for details on	how to setup a secure distrib-
	     uted node.

	   inet6_tcp:
	     TCP over IPv6

	   For example,	to start up IPv6 distributed nodes:

	 % erl -name test@ipv6node.example.com -proto_dist inet6_tcp

	 -remsh	Node:
	   Starts Erlang with a	remote shell connected to Node.

	   If  no  -name  or  -sname  is  given	the node will be started using
	   -sname undefined. If	Node does not contain a	hostname, one is auto-
	   matically taken from	-name or -sname

     Note:
	 Before	 OTP-23	 the user needed to supply a valid -sname or -name for
	 -remsh	to work. This is still the case	if the target node is not run-
	 ning OTP-23 or	later.

	 -rsh Program:
	   Specifies  an alternative to	ssh for	starting a slave node on a re-
	   mote	host; see slave(3).

	 -run Mod [Func	[Arg1, Arg2, ...]] (init flag):
	   Makes init call the specified function. Func	defaults to start.  If
	   no  arguments  are provided,	the function is	assumed	to be of arity
	   0. Otherwise	it is assumed to  be  of  arity	 1,  taking  the  list
	   [Arg1,Arg2,...]  as	argument. All arguments	are passed as strings.
	   See init(3).

	 -s Mod	[Func [Arg1, Arg2, ...]] (init flag):
	   Makes init call the specified function. Func	defaults to start.  If
	   no  arguments  are provided,	the function is	assumed	to be of arity
	   0. Otherwise	it is assumed to  be  of  arity	 1,  taking  the  list
	   [Arg1,Arg2,...] as argument.	All arguments are passed as atoms. See
	   init(3).

	 -setcookie Cookie:
	   Sets	 the  magic  cookie  of	 the   node   to   Cookie;   see   er-
	   lang:set_cookie/2.

	 -setcookie Node Cookie:
	   Sets	the magic cookie for Node to Cookie; see erlang:set_cookie/2.

	 -shutdown_time	Time:
	   Specifies  how  long	time (in milliseconds) the init	process	is al-
	   lowed to spend shutting down	the system. If Time milliseconds  have
	   elapsed,  all  processes still existing are killed. Defaults	to in-
	   finity.

	 -sname	Name:
	   Makes the Erlang runtime system into	a distributed node, similar to
	   -name, but the host name portion of the node	name Name@Host will be
	   the short name, not fully qualified.

	   This	is sometimes the only way to run distributed Erlang if the Do-
	   main	 Name  System (DNS) is not running. No communication can exist
	   between nodes running with flag -sname and those running with  flag
	   -name, as node names	must be	unique in distributed Erlang systems.

     Warning:
	 Starting  a  distributed  node	 without  also	specifying -proto_dist
	 inet_tls will expose the node to attacks that may give	 the  attacker
	 complete  access to the node and in extension the cluster. When using
	 un-secure distributed nodes, make sure	that the network is configured
	 to keep potential attackers out.

	 -start_epmd true | false:
	   Specifies  whether  Erlang should start epmd	on startup. By default
	   this	is true, but if	you prefer to start epmd manually, set this to
	   false.

	   This	 only applies if Erlang	is started as a	distributed node, i.e.
	   if -name or -sname is specified. Otherwise,	epmd  is  not  started
	   even	if -start_epmd true is given.

	   Note	that a distributed node	will fail to start if epmd is not run-
	   ning.

	 -version (emulator flag):
	   Makes the emulator print its	version	number.	The same as erl	+V.

EMULATOR FLAGS
       erl invokes the code for	the Erlang emulator (virtual  machine),	 which
       supports	the following flags:

	 +a size:
	   Suggested stack size, in kilowords, for threads in the async	thread
	   pool. Valid range is	16-8192	kilowords. The default suggested stack
	   size	is 16 kilowords, that is, 64 kilobyte on 32-bit	architectures.
	   This	small default size has been chosen because the number of async
	   threads can be large. The default size is enough for	drivers	deliv-
	   ered	with Erlang/OTP, but might not be large	enough for  other  dy-
	   namically linked-in drivers that use	the driver_async() functional-
	   ity.	Notice that the	value passed is	only a suggestion, and it  can
	   even	be ignored on some platforms.

	 +A size:
	   Sets	 the  number  of  threads in async thread pool.	Valid range is
	   1-1024. The async thread pool is used by linked-in drivers to  han-
	   dle	work  that  may	 take a	very long time.	Since OTP 21 there are
	   very	few linked-in drivers in the default  Erlang/OTP  distribution
	   that	uses the async thread pool. Most of them have been migrated to
	   dirty IO schedulers.	Defaults to 1.

	 +B [c | d | i]:
	   Option c makes Ctrl-C interrupt the current shell instead of	invok-
	   ing	the  emulator  break  handler. Option d	(same as specifying +B
	   without an extra option) disables the break handler.	Option i makes
	   the emulator	ignore any break signal.

	   If  option c	is used	with oldshell on Unix, Ctrl-C will restart the
	   shell process rather	than interrupt it.

	   Notice that on Windows, this	flag is	only applicable	for werl,  not
	   erl	(oldshell).  Notice  also  that	 Ctrl-Break is used instead of
	   Ctrl-C on Windows.

	 +c true | false:
	   Enables or disables time correction:

	   true:
	     Enables time correction. This is the default if  time  correction
	     is	supported on the specific platform.

	   false:
	     Disables time correction.

	   For	backward compatibility,	the boolean value can be omitted. This
	   is interpreted as +c	false.

	 +C no_time_warp | single_time_warp | multi_time_warp:
	   Sets	time warp mode:

	   no_time_warp:
	      No time warp mode	(the default)

	   single_time_warp:
	      Single time warp mode

	   multi_time_warp:
	      Multi-time warp mode

	 +d:
	   If the emulator detects an internal error (or runs out of  memory),
	   it,	by  default,  generates	both a crash dump and a	core dump. The
	   core	dump is, however, not very useful as the  content  of  process
	   heaps is destroyed by the crash dump	generation.

	   Option +d instructs the emulator to produce only a core dump	and no
	   crash dump if an internal error is detected.

	   Calling erlang:halt/1 with a	string argument	still produces a crash
	   dump. On Unix systems, sending an emulator process a	SIGUSR1	signal
	   also	forces a crash dump.

	 +dcg DecentralizedCounterGroupsLimit:
	   Limits the number of	decentralized counter groups  used  by	decen-
	   tralized  counters  optimized  for  update operations in the	Erlang
	   runtime system. By default, the limit is 256.

	   When	the number of schedulers is less than or equal to  the	limit,
	   each	 scheduler has its own group. When the number of schedulers is
	   larger than the  groups  limit,  schedulers	share  groups.	Shared
	   groups  degrade  the	 performance  for updating counters while many
	   reader groups degrade the performance for reading counters. So, the
	   limit  is  a	tradeoff between performance for update	operations and
	   performance for read	operations. Each group consumes	 64  bytes  in
	   each	counter.

	   Notice  that	 a  runtime  system using decentralized	counter	groups
	   benefits from binding schedulers  to	 logical  processors,  as  the
	   groups are distributed better between schedulers with this option.

	   This	 option	only affects decentralized counters used for the coun-
	   ters	that are keeping track of the memory consumption and the  num-
	   ber	of terms in ETS	tables of type ordered_set with	the write_con-
	   currency option activated.

	 +e Number:
	   Sets	the maximum number of ETS tables. This limit is	partially  ob-
	   solete.

	 +ec:
	   Forces  option compressed on	all ETS	tables.	Only intended for test
	   and evaluation.

	 +fnl:
	   The virtual machine works with filenames as if they are encoded us-
	   ing	the  ISO Latin-1 encoding, disallowing Unicode characters with
	   code	points > 255.

	   For more information	about Unicode filenames, see  section  Unicode
	   Filenames  in  the STDLIB User's Guide. Notice that this value also
	   applies to command-line parameters and environment  variables  (see
	   section  Unicode in Environment and Parameters in the STDLIB	User's
	   Guide).

	 +fnu[{w|i|e}]:
	   The virtual machine works with filenames as if they are encoded us-
	   ing UTF-8 (or some other system-specific Unicode encoding). This is
	   the default on operating systems  that  enforce  Unicode  encoding,
	   that	is, Windows MacOS X and	Android.

	   The	+fnu  switch  can  be  followed	 by  w,	i, or e	to control how
	   wrongly encoded filenames are to be reported:

	   * w means that a warning is sent to	the  error_logger  whenever  a
	     wrongly encoded filename is "skipped" in directory	listings. This
	     is	the default.

	   * i means that those	wrongly	encoded	 filenames  are	 silently  ig-
	     nored.

	   * e means that the API function returns an error whenever a wrongly
	     encoded filename (or directory name) is encountered.

	   Notice that file:read_link/1	always returns an error	 if  the  link
	   points to an	invalid	filename.

	   For	more  information about	Unicode	filenames, see section Unicode
	   Filenames in	the STDLIB User's Guide. Notice	that this  value  also
	   applies  to	command-line parameters	and environment	variables (see
	   section  Unicode in Environment and Parameters in the STDLIB	User's
	   Guide).

	 +fna[{w|i|e}]:
	   Selection between +fnl and +fnu is done based on the	current	locale
	   settings in the OS. This means that if you have set	your  terminal
	   for	UTF-8 encoding,	the filesystem is expected to use the same en-
	   coding for filenames. This is the default on	all operating systems,
	   except Android, MacOS X and Windows.

	   The	+fna  switch can be followed by	w, i, or e. This has effect if
	   the locale settings cause the behavior of +fnu to be	selected;  see
	   the description of +fnu above. If the locale	settings cause the be-
	   havior of +fnl to be	selected, then w, i, or	e have no effect.

	   For more information	about Unicode filenames, see  section  Unicode
	   Filenames  in  the STDLIB User's Guide. Notice that this value also
	   applies to command-line parameters and environment  variables  (see
	   section  Unicode in Environment and Parameters in the STDLIB	User's
	   Guide).

	 +hms Size:
	   Sets	the default heap size of processes to the size Size.

	 +hmbs Size:
	   Sets	the default binary virtual heap	size of	processes to the  size
	   Size.

	 +hmax Size:
	   Sets	 the  default maximum heap size	of processes to	the size Size.
	   Defaults to 0, which	means that no maximum heap size	is  used.  For
	   more	information, see process_flag(max_heap_size, MaxHeapSize).

	 +hmaxel true|false:
	   Sets	 whether  to send an error logger message or not for processes
	   reaching the	maximum	heap size. Defaults to true. For more informa-
	   tion, see process_flag(max_heap_size, MaxHeapSize).

	 +hmaxk	true|false:
	   Sets	 whether  to  kill processes reaching the maximum heap size or
	   not.	  Default    to	   true.    For	   more	   information,	   see
	   process_flag(max_heap_size, MaxHeapSize).

	 +hpds Size:
	   Sets	 the  initial process dictionary size of processes to the size
	   Size.

	 +hmqd off_heap|on_heap:
	   Sets	the default value of the message_queue_data process flag.  De-
	   faults  to on_heap. If +hmqd	is not passed, on_heap will be the de-
	   fault. For more information,	 see  process_flag(message_queue_data,
	   MQD).

	 +IOp PollSets:
	   Sets	 the  number  of IO pollsets to	use when polling for I/O. This
	   option is only used on platforms that support concurrent updates of
	   a  pollset,	otherwise  the	same number of pollsets	are used as IO
	   poll	threads. The default is	1.

	 +IOt PollThreads:
	   Sets	the number of IO poll threads to use when polling for I/O. The
	   maximum number of poll threads allowed is 1024. The default is 1.

	   A  good  way	 to check if more IO poll threads are needed is	to use
	   microstate accounting and see what the load of the IO  poll	thread
	   is. If it is	high it	could be a good	idea to	add more threads.

	 +IOPp PollSetsPercentage:
	   Similar  to	+IOp  but  uses	 percentages  to  set the number of IO
	   pollsets to create, based on	the number of poll threads configured.
	   If both +IOPp and +IOp are used, +IOPp is ignored.

	 +IOPt PollThreadsPercentage:
	   Similar  to	+IOt but uses percentages to set the number of IO poll
	   threads to create, based on the number of schedulers	configured. If
	   both	+IOPt and +IOt are used, +IOPt is ignored.

	 +JPperf true|false:
	   Enables  or	disables  support for the `perf` profiler when running
	   with	the JIT	on Linux. Defaults to false.

	   For more details about how to run perf see the perf support section
	   in the BeamAsm internal documentation.

	 +L:
	   Prevents  loading  information about	source filenames and line num-
	   bers. This saves some memory, but exceptions	do not contain	infor-
	   mation about	the filenames and line numbers.

	 +MFlag	Value:
	   Memory allocator-specific flags. For	more information, see erts_al-
	   loc(3).

	 +pc Range:
	   Sets	the range of characters	that the system	considers printable in
	   heuristic  detection	 of strings. This typically affects the	shell,
	   debugger, and io:format functions (when ~tp is used in  the	format
	   string).

	   Two values are supported for	Range:

	   latin1:
	     The default. Only characters in the ISO Latin-1 range can be con-
	     sidered printable.	This means that	a character with a code	 point
	     >	255  is	 never	considered printable and that lists containing
	     such characters are displayed as lists of	integers  rather  than
	     text strings by tools.

	   unicode:
	     All  printable Unicode characters are considered when determining
	     if	a list of integers is to be displayed in string	 syntax.  This
	     can  give	unexpected results if, for example, your font does not
	     cover all Unicode characters.

	   See also io:printable_range/0 in STDLIB.

	 +P Number:
	   Sets	the maximum number of simultaneously  existing	processes  for
	   this	 system	if a Number is passed as value.	Valid range for	Number
	   is [1024-134217727]

	   NOTE: The actual maximum chosen may be much larger than the	Number
	   passed. Currently the runtime system	often, but not always, chooses
	   a value that	is a power of 2. This might, however,  be  changed  in
	   the	future.	 The actual value chosen can be	checked	by calling er-
	   lang:system_info(process_limit).

	   The default value is	262144

	 +Q Number:
	   Sets	the maximum number of simultaneously existing ports  for  this
	   system  if  a  Number is passed as value. Valid range for Number is
	   [1024-134217727]

	   NOTE: The actual maximum chosen may be much larger than the	actual
	   Number  passed. Currently the runtime system	often, but not always,
	   chooses a value that	is a power  of	2.  This  might,  however,  be
	   changed  in	the  future. The actual	value chosen can be checked by
	   calling erlang:system_info(port_limit).

	   The default value used is normally 65536. However, if  the  runtime
	   system is able to determine maximum amount of file descriptors that
	   it is allowed to open and this value	is larger than 65536, the cho-
	   sen	value will increased to	a value	larger or equal	to the maximum
	   amount of file descriptors that can be opened.

	   On Windows the default value	is set to 8196 because the  normal  OS
	   limitations are set higher than most	machines can handle.

	 +R ReleaseNumber:
	   Sets	the compatibility mode.

	   The	distribution  mechanism	is not backward	compatible by default.
	   This	flag sets the emulator in compatibility	mode with  an  earlier
	   Erlang/OTP release ReleaseNumber. The release number	must be	in the
	   range _current release_-2.._current release_. This limits the  emu-
	   lator,  making  it possible for it to communicate with Erlang nodes
	   (as well as C- and Java nodes) running that earlier release.

     Note:
	 Ensure	that all nodes (Erlang-, C-, and Java nodes) of	a  distributed
	 Erlang	 system	is of the same Erlang/OTP release, or from two differ-
	 ent Erlang/OTP	releases X and Y, where	all Y nodes have compatibility
	 mode X.

	 +r:
	   Forces ETS memory block to be moved on realloc.

	 +rg ReaderGroupsLimit:
	   Limits  the	number of reader groups	used by	read/write locks opti-
	   mized for read operations in	the Erlang runtime system. By  default
	   the reader groups limit is 64.

	   When	 the  number of	schedulers is less than	or equal to the	reader
	   groups limit, each scheduler	has its	own  reader  group.  When  the
	   number of schedulers	is larger than the reader groups limit,	sched-
	   ulers share reader groups. Shared reader groups degrade  read  lock
	   and	read unlock performance	while many reader groups degrade write
	   lock	performance. So, the limit is a	tradeoff  between  performance
	   for	read  operations  and  performance  for	write operations. Each
	   reader group	consumes 64 byte in each read/write lock.

	   Notice that a runtime system	using shared  reader  groups  benefits
	   from	binding	schedulers to logical processors, as the reader	groups
	   are distributed better between schedulers.

	 +S Schedulers:SchedulerOnline:
	   Sets	the number  of	scheduler  threads  to	create	and  scheduler
	   threads  to set online. The maximum for both	values is 1024.	If the
	   Erlang runtime system is able to determine the  number  of  logical
	   processors  configured and logical processors available, Schedulers
	   defaults to logical processors configured, and SchedulersOnline de-
	   faults  to logical processors available; otherwise the default val-
	   ues are 1. If the emulator detects that it  is  subject  to	a  CPU
	   quota,  the	default	value for SchedulersOnline will	be limited ac-
	   cordingly.

	   Schedulers can be omitted  if  :SchedulerOnline  is	not  and  con-
	   versely.  The number	of schedulers online can be changed at runtime
	   through erlang:system_flag(schedulers_online, SchedulersOnline).

	   If Schedulers or SchedulersOnline is	specified as a	negative  num-
	   ber,	 the  value  is	 subtracted from the default number of logical
	   processors configured  or  logical  processors  available,  respec-
	   tively.

	   Specifying  value  0	 for Schedulers	or SchedulersOnline resets the
	   number of scheduler threads or scheduler  threads  online,  respec-
	   tively, to its default value.

	 +SP SchedulersPercentage:SchedulersOnlinePercentage:
	   Similar  to	+S but uses percentages	to set the number of scheduler
	   threads to create, based  on	 logical  processors  configured,  and
	   scheduler threads to	set online, based on logical processors	avail-
	   able. Specified values must be > 0. For example, +SP	50:25 sets the
	   number  of  scheduler threads to 50%	of the logical processors con-
	   figured, and	the number of scheduler	threads	online to 25%  of  the
	   logical  processors	available. SchedulersPercentage	can be omitted
	   if :SchedulersOnlinePercentage is not and conversely. The number of
	   schedulers  online  can  be	changed	at runtime through erlang:sys-
	   tem_flag(schedulers_online, SchedulersOnline).

	   This	option interacts with +S settings. For example,	 on  a	system
	   with	 8 logical cores configured and	8 logical cores	available, the
	   combination of the options +S 4:4 +SP 50:25 (in either  order)  re-
	   sults  in 2 scheduler threads (50% of 4) and	1 scheduler thread on-
	   line	(25% of	4).

	 +SDcpu	DirtyCPUSchedulers:DirtyCPUSchedulersOnline:
	   Sets	the number of dirty CPU	scheduler threads to create and	 dirty
	   CPU scheduler threads to set	online.	The maximum for	both values is
	   1024, and each value	is further limited by the settings for	normal
	   schedulers:

	   * The  number  of dirty CPU scheduler threads created cannot	exceed
	     the number	of normal scheduler threads created.

	   * The number	of dirty CPU scheduler threads	online	cannot	exceed
	     the number	of normal scheduler threads online.

	   For	details,  see  the +S and +SP. By default, the number of dirty
	   CPU scheduler threads created equals	the number of normal scheduler
	   threads  created, and the number of dirty CPU scheduler threads on-
	   line	equals the number of normal scheduler threads online.  DirtyC-
	   PUSchedulers	can be omitted if :DirtyCPUSchedulersOnline is not and
	   conversely. The number  of  dirty  CPU  schedulers  online  can  be
	   changed   at	 runtime  through  erlang:system_flag(dirty_cpu_sched-
	   ulers_online, DirtyCPUSchedulersOnline).

	   The amount of dirty CPU schedulers is limited by the	amount of nor-
	   mal	schedulers in order to limit the effect	on processes executing
	   on ordinary schedulers. If the amount of dirty CPU  schedulers  was
	   allowed  to	be  unlimited,	dirty CPU bound	jobs would potentially
	   starve normal jobs.

	   Typical users of the	dirty CPU schedulers are large garbage collec-
	   tions, json protocol	encode/decoders	written	as nifs	and matrix ma-
	   nipulation libraries.

	   You can use msacc(3)	in order to see	the current load of the	 dirty
	   CPU schedulers threads and adjust the number	used accordingly.

	 +SDPcpu DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercent-
	 age:
	   Similar to +SDcpu but uses percentages to set the number  of	 dirty
	   CPU	scheduler threads to create and	the number of dirty CPU	sched-
	   uler	threads	to set online. Specified values	must be	> 0. For exam-
	   ple,	 +SDPcpu  50:25	sets the number	of dirty CPU scheduler threads
	   to 50% of the logical processors configured and the number of dirty
	   CPU	scheduler  threads  online  to	25%  of	the logical processors
	   available. DirtyCPUSchedulersPercentage can be omitted if  :DirtyC-
	   PUSchedulersOnlinePercentage	 is  not and conversely. The number of
	   dirty CPU schedulers	online can be changed at runtime  through  er-
	   lang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOn-
	   line).

	   This	option interacts with +SDcpu settings. For example, on a  sys-
	   tem	with 8 logical cores configured	and 8 logical cores available,
	   the combination of the options +SDcpu 4:4 +SDPcpu 50:25 (in	either
	   order)  results  in	2 dirty	CPU scheduler threads (50% of 4) and 1
	   dirty CPU scheduler thread online (25% of 4).

	 +SDio DirtyIOSchedulers:
	   Sets	the number of dirty I/O	scheduler  threads  to	create.	 Valid
	   range  is  1-1024.  By  default,  the number	of dirty I/O scheduler
	   threads created is 10.

	   The amount of dirty IO schedulers is	not limited by the  amount  of
	   normal  schedulers  like  the  amount of dirty CPU schedulers. This
	   since only I/O bound	work is	 expected  to  execute	on  dirty  I/O
	   schedulers. If the user should schedule CPU bound jobs on dirty I/O
	   schedulers, these jobs might	starve ordinary	jobs executing on  or-
	   dinary schedulers.

	   Typical users of the	dirty IO schedulers are	reading	and writing to
	   files.

	   You can use msacc(3)	in order to see	the current load of the	 dirty
	   IO schedulers threads and adjust the	number used accordingly.

	 +sFlag	Value:
	   Scheduling specific flags.

	   +sbt	BindType:
	     Sets scheduler bind type.

	     Schedulers	 can  also be bound using flag +stbt. The only differ-
	     ence between these	two flags is how the following errors are han-
	     dled:

	     * Binding	of  schedulers	is not supported on the	specific plat-
	       form.

	     * No available CPU	topology. That is, the runtime system was  not
	       able  to	detect the CPU topology	automatically, and no user-de-
	       fined CPU topology was set.

	     If	any of these errors occur when +sbt has	been passed, the  run-
	     time system prints	an error message, and refuses to start.	If any
	     of	these errors occur when	+stbt has  been	 passed,  the  runtime
	     system  silently  ignores	the  error, and	start up using unbound
	     schedulers.

	     Valid BindTypes:

	     u:
	       unbound - Schedulers are	not bound to logical processors,  that
	       is,  the	 operating  system decides where the scheduler threads
	       execute,	and when to migrate them. This is the default.

	     ns:
	       no_spread - Schedulers with  close  scheduler  identifiers  are
	       bound as	close as possible in hardware.

	     ts:
	       thread_spread  -	Thread refers to hardware threads (such	as In-
	       tel's hyper-threads). Schedulers	 with  low  scheduler  identi-
	       fiers,  are  bound  to  the first hardware thread of each core,
	       then schedulers with higher scheduler identifiers are bound  to
	       the second hardware thread of each core,and so on.

	     ps:
	       processor_spread	 -  Schedulers	are spread like	thread_spread,
	       but also	over physical processor	chips.

	     s:
	       spread -	Schedulers are spread as much as possible.

	     nnts:
	       no_node_thread_spread - Like  thread_spread,  but  if  multiple
	       Non-Uniform  Memory  Access  (NUMA) nodes exist,	schedulers are
	       spread over one NUMA node at a time, that is, all logical  pro-
	       cessors of one NUMA node	are bound to schedulers	in sequence.

	     nnps:
	       no_node_processor_spread	- Like processor_spread, but if	multi-
	       ple NUMA	nodes exist, schedulers	are spread over	one NUMA  node
	       at a time, that is, all logical processors of one NUMA node are
	       bound to	schedulers in sequence.

	     tnnps:
	       thread_no_node_processor_spread	  -    A    combination	    of
	       thread_spread,  and  no_node_processor_spread.  Schedulers  are
	       spread over hardware threads across NUMA	nodes, but  schedulers
	       are  only spread	over processors	internally in one NUMA node at
	       a time.

	     db:
	       default_bind - Binds schedulers the default  way.  Defaults  to
	       thread_no_node_processor_spread	(which	can  change in the fu-
	       ture).

	     Binding of	schedulers is only supported on	newer Linux,  Solaris,
	     FreeBSD, and Windows systems.

	     If	 no  CPU topology is available when flag +sbt is processed and
	     BindType is any other type	than u,	the runtime  system  fails  to
	     start.  CPU  topology can be defined using	flag +sct. Notice that
	     flag +sct can have	to be passed before flag +sbt on  the  command
	     line (if no CPU topology has been automatically detected).

	     The runtime system	does by	default	not bind schedulers to logical
	     processors.

       Note:
	   If the Erlang runtime system	is the only operating  system  process
	   that	binds threads to logical processors, this improves the perfor-
	   mance of the	runtime	system.	However,  if  other  operating	system
	   processes  (for  example  another  Erlang runtime system) also bind
	   threads to logical processors, there	can be a  performance  penalty
	   instead.  This  performance penalty can sometimes be	severe.	If so,
	   you are advised not to bind the schedulers.

	     How schedulers are	bound matters. For example, in situations when
	     there  are	 fewer	running	 processes than	schedulers online, the
	     runtime system tries to migrate processes to schedulers with  low
	     scheduler	identifiers.  The  more	the schedulers are spread over
	     the hardware, the more resources are  available  to  the  runtime
	     system in such situations.

       Note:
	   If a	scheduler fails	to bind, this is often silently	ignored, as it
	   is not always possible to verify valid  logical  processor  identi-
	   fiers. If an	error is reported, it is reported to the error_logger.
	   If you want to verify that the schedulers have bound	as  requested,
	   call	erlang:system_info(scheduler_bindings).

	   +sbwt none|very_short|short|medium|long|very_long:
	     Sets  scheduler  busy  wait  threshold.  Defaults	to medium. The
	     threshold determines how long schedulers are to  busy  wait  when
	     running out of work before	going to sleep.

       Note:
	   This	 flag  can be removed or changed at any	time without prior no-
	   tice.

	   +sbwtdcpu none|very_short|short|medium|long|very_long:
	     As	+sbwt but affects dirty	CPU schedulers.	Defaults to short.

       Note:
	   This	flag can be removed or changed at any time without  prior  no-
	   tice.

	   +sbwtdio none|very_short|short|medium|long|very_long:
	     As	+sbwt but affects dirty	IO schedulers. Defaults	to short.

       Note:
	   This	 flag  can be removed or changed at any	time without prior no-
	   tice.

	   +scl	true|false:
	     Enables or	disables scheduler  compaction	of  load.  By  default
	     scheduler	compaction of load is enabled. When enabled, load bal-
	     ancing strives for	a load	distribution,  which  causes  as  many
	     scheduler	threads	 as  possible to be fully loaded (that is, not
	     run out of	work). This is accomplished by migrating load (for ex-
	     ample,  runnable processes) into a	smaller	set of schedulers when
	     schedulers	frequently run out of work. When  disabled,  the  fre-
	     quency  with  which  schedulers run out of	work is	not taken into
	     account by	the load balancing logic.

	     +scl false	is similar to +sub true, but +sub true	also  balances
	     scheduler utilization between schedulers.

	   +sct	CpuTopology:

	     * _Id_ = integer(); when 0	=_ _Id_	=_ 65535

	     * _IdRange_ = _Id_-_Id_

	     * _IdOrIdRange_ = _Id_ | _IdRange_

	     * _IdList_	= _IdOrIdRange_,_IdOrIdRange_ |	_IdOrIdRange_

	     * _LogicalIds_ = L_IdList_

	     * _ThreadIds_ = T_IdList_ | t_IdList_

	     * _CoreIds_ = C_IdList_ | c_IdList_

	     * _ProcessorIds_ =	P_IdList_ | p_IdList_

	     * _NodeIds_ = N_IdList_ | n_IdList_

	     * _IdDefs_	      =	      _LogicalIds__ThreadIds__CoreIds__Proces-
	       sorIds__NodeIds_		|	  _LogicalIds__ThreadIds__Cor-
	       eIds__NodeIds__ProcessorIds_

	     * CpuTopology = _IdDefs_:_IdDefs_ | _IdDefs_

	     Sets  a  user-defined CPU topology. The user-defined CPU topology
	     overrides any automatically detected CPU topology.	The CPU	topol-
	     ogy is used when binding schedulers to logical processors.

	     Uppercase	letters	signify	real identifiers and lowercase letters
	     signify fake identifiers only used	for description	of the	topol-
	     ogy.  Identifiers	passed	as real	identifiers can	be used	by the
	     runtime system when trying	to access specific hardware;  if  they
	     are  incorrect the	behavior is undefined. Faked logical CPU iden-
	     tifiers are not accepted, as there	is no point  in	 defining  the
	     CPU  topology without real	logical	CPU identifiers. Thread, core,
	     processor,	and node identifiers can be omitted. If	 omitted,  the
	     thread ID defaults	to t0, the core	ID defaults to c0, the proces-
	     sor ID defaults to	p0, and	the node ID is left undefined.	Either
	     each  logical  processor must belong to only one NUMA node, or no
	     logical processors	must belong to any NUMA	nodes.

	     Both increasing and decreasing _IdRange_s are allowed.

	     NUMA node identifiers are system wide. That is, each NUMA node on
	     the  system  must have a unique identifier. Processor identifiers
	     are also system wide. Core	identifiers are	processor wide.	Thread
	     identifiers are core wide.

	     The  order	 of  the identifier types implies the hierarchy	of the
	     CPU topology. The valid orders are	as follows:

	     * _LogicalIds__ThreadIds__CoreIds__ProcessorIds__NodeIds_,	  that
	       is, thread is part of a core that is part of a processor, which
	       is part of a NUMA node.

	     * _LogicalIds__ThreadIds__CoreIds__NodeIds__ProcessorIds_,	  that
	       is, thread is part of a core that is part of a NUMA node, which
	       is part of a processor.

	     A CPU topology can	consist	of both	processor external,  and  pro-
	     cessor  internal NUMA nodes as long as each logical processor be-
	     longs to only one NUMA node. If _ProcessorIds_  is	 omitted,  its
	     default  position	is  before  _NodeIds_. That is,	the default is
	     processor external	NUMA nodes.

	     If	a list of identifiers is used in an _IdDefs_:

	     * _LogicalIds_ must be a list of identifiers.

	     * At least	one other identifier type  besides  _LogicalIds_  must
	       also have a list	of identifiers.

	     * All  lists of identifiers must produce the same number of iden-
	       tifiers.

	     A simple example. A single	quad core processor can	 be  described
	     as	follows:

	   % erl +sct L0-3c0-3
	   1> erlang:system_info(cpu_topology).
	   [{processor,[{core,{logical,0}},
			{core,{logical,1}},
			{core,{logical,2}},
			{core,{logical,3}}]}]

	     A	more  complicated  example with	two quad core processors, each
	     processor in its own NUMA node. The ordering of  logical  proces-
	     sors  is a	bit weird. This	to give	a better example of identifier
	     lists:

	   % erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
	   1> erlang:system_info(cpu_topology).
	   [{node,[{processor,[{core,{logical,0}},
			       {core,{logical,1}},
			       {core,{logical,3}},
			       {core,{logical,2}}]}]},
	    {node,[{processor,[{core,{logical,7}},
			       {core,{logical,4}},
			       {core,{logical,6}},
			       {core,{logical,5}}]}]}]

	     As	long as	real identifiers are correct, it is OK to pass	a  CPU
	     topology  that  is	not a correct description of the CPU topology.
	     When used with care this can be very useful. This	to  trick  the
	     emulator  to bind its schedulers as you want. For example,	if you
	     want to run multiple Erlang runtime systems on the	same  machine,
	     you  want	to reduce the number of	schedulers used	and manipulate
	     the CPU topology so that they bind	to different logical CPUs.  An
	     example, with two Erlang runtime systems on a quad	core machine:

	   % erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput	-noshell -sname	one
	   % erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput	-noshell -sname	two

	     In	this example, each runtime system have two schedulers each on-
	     line, and all schedulers online will run on different  cores.  If
	     we	 change	 to  one  scheduler  online on one runtime system, and
	     three schedulers online on	the other, all schedulers online  will
	     still run on different cores.

	     Notice  that  a  faked CPU	topology that does not reflect how the
	     real CPU topology looks like is likely to	decrease  the  perfor-
	     mance of the runtime system.

	     For more information, see erlang:system_info(cpu_topology).

	   +sfwi Interval:
	     Sets scheduler-forced wakeup interval. All	run queues are scanned
	     each Interval milliseconds. While there are  sleeping  schedulers
	     in	 the  system,  one  scheduler  is woken	for each non-empty run
	     queue found. Interval default to 0, meaning this feature is  dis-
	     abled.

       Note:
	   This	 feature  has  been  introduced	 as a temporary	workaround for
	   long-executing native code, and native code that does not bump  re-
	   ductions  properly  in  OTP.	 When these bugs have been fixed, this
	   flag	will be	removed.

	   +spp	Bool:
	     Sets default scheduler hint for port parallelism. If set to true,
	     the  virtual machine schedules port tasks when it improves	paral-
	     lelism in the system. If set to false, the	virtual	machine	 tries
	     to	 perform  port tasks immediately, improving latency at the ex-
	     pense of parallelism. Default to false. The default used  can  be
	     inspected in runtime by calling erlang:system_info(port_parallel-
	     ism). The default can be overridden on port creation  by  passing
	     option parallelism	to erlang:open_port/2.

	   +sss	size:
	     Suggested	stack size, in kilowords, for scheduler	threads. Valid
	     range is 20-8192 kilowords. The default suggested stack  size  is
	     128 kilowords.

	   +sssdcpu size:
	     Suggested	stack  size,  in  kilowords,  for  dirty CPU scheduler
	     threads. Valid range is 20-8192 kilowords.	The default  suggested
	     stack size	is 40 kilowords.

	   +sssdio size:
	     Suggested	stack  size,  in  kilowords,  for  dirty  IO scheduler
	     threads. Valid range is 20-8192 kilowords.	The default  suggested
	     stack size	is 40 kilowords.

	   +stbt BindType:
	     Tries  to	set the	scheduler bind type. The same as flag +sbt ex-
	     cept how some errors are handled. For more	information, see +sbt.

	   +sub	true|false:
	     Enables or	disables  scheduler utilization	balancing of load.  By
	     default  scheduler	 utilization balancing is disabled and instead
	     scheduler compaction of load is enabled, which strives for	a load
	     distribution that causes as many scheduler	threads	as possible to
	     be	fully loaded (that is, not run out of  work).  When  scheduler
	     utilization  balancing  is	 enabled,  the system instead tries to
	     balance scheduler utilization between schedulers. That is,	strive
	     for equal scheduler utilization on	all schedulers.

	     +sub  true	 is only supported on systems where the	runtime	system
	     detects  and  uses	 a  monotonically  increasing  high-resolution
	     clock. On other systems, the runtime system fails to start.

	     +sub  true	 implies  +scl false. The difference between +sub true
	     and +scl false is that +scl false does not	 try  to  balance  the
	     scheduler utilization.

	   +swct very_eager|eager|medium|lazy|very_lazy:
	     Sets  scheduler  wake cleanup threshold. Defaults to medium. Con-
	     trols how eager schedulers	are to be requesting wakeup because of
	     certain  cleanup  operations.  When  a lazy setting is used, more
	     outstanding cleanup operations can	be left	undone while a	sched-
	     uler  is  idling.	When  an eager setting is used,	schedulers are
	     more frequently woken, potentially	increasing CPU-utilization.

       Note:
	   This	flag can be removed or changed at any time without  prior  no-
	   tice.

	   +sws	default|legacy:
	     Sets  scheduler wakeup strategy. Default strategy changed in ERTS
	     5.10 (Erlang/OTP R16A). This strategy was known  as  proposal  in
	     Erlang/OTP	 R15. The legacy strategy was used as default from R13
	     up	to and including R15.

       Note:
	   This	flag can be removed or changed at any time without  prior  no-
	   tice.

	   +swt	very_low|low|medium|high|very_high:
	     Sets  scheduler wakeup threshold. Defaults	to medium. The thresh-
	     old determines when to wake up sleeping schedulers	when more work
	     than  can	be handled by currently	awake schedulers exists. A low
	     threshold causes earlier wakeups, and  a  high  threshold	causes
	     later wakeups. Early wakeups distribute work over multiple	sched-
	     ulers faster, but work does more  easily  bounce  between	sched-
	     ulers.

       Note:
	   This	 flag  can be removed or changed at any	time without prior no-
	   tice.

	   +swtdcpu very_low|low|medium|high|very_high:
	     As	+swt but affects dirty CPU schedulers. Defaults	to medium.

       Note:
	   This	flag can be removed or changed at any time without  prior  no-
	   tice.

	   +swtdio very_low|low|medium|high|very_high:
	     As	+swt but affects dirty IO schedulers. Defaults to medium.

       Note:
	   This	 flag  can be removed or changed at any	time without prior no-
	   tice.

	 +t size:
	   Sets	the maximum number of atoms the	virtual	 machine  can  handle.
	   Defaults to 1,048,576.

	 +T Level:
	   Enables  modified  timing and sets the modified timing level. Valid
	   range is 0-9. The timing of the runtime system is changed.  A  high
	   level usually means a greater change	than a low level. Changing the
	   timing can be very useful for finding timing-related	bugs.

	   Modified timing affects the following:

	   Process spawning:
	     A process calling spawn, spawn_link, spawn_monitor, or  spawn_opt
	     is	 scheduled  out	 immediately  after  completing	the call. When
	     higher modified timing levels are used, the  caller  also	sleeps
	     for a while after it is scheduled out.

	   Context reductions:
	     The number	of reductions a	process	is allowed to use before it is
	     scheduled out is increased	or reduced.

	   Input reductions:
	     The number	of reductions performed	before	checking  I/O  is  in-
	     creased or	reduced.

     Note:
	 Performance  suffers  when  modified  timing is enabled. This flag is
	 only intended for testing and debugging.

	 return_to and return_from trace messages are lost when	tracing	on the
	 spawn BIFs.

	 This flag can be removed or changed at	any time without prior notice.

	 +v:
	   Verbose.

	 +V:
	   Makes the emulator print its	version	number.

	 +W w |	i | e:
	   Sets	 the  mapping  of  warning messages for	error_logger. Messages
	   sent	to the error logger using one of the warning routines  can  be
	   mapped  to  errors  (+W e), warnings	(+W w),	or information reports
	   (+W i). Defaults to warnings. The current mapping can be  retrieved
	   using  error_logger:warning_map/0.  For  more  information, see er-
	   ror_logger:warning_map/0 in Kernel.

	 +zFlag	Value:
	   Miscellaneous flags:

	   +zdbbl size:
	     Sets the distribution buffer busy limit (dist_buf_busy_limit)  in
	     kilobytes.	Valid range is 1-2097151. Defaults to 1024.

	     A	larger	buffer	limit allows processes to buffer more outgoing
	     messages over the distribution. When the buffer  limit  has  been
	     reached,  sending	processes  will	 be suspended until the	buffer
	     size has shrunk. The buffer limit is per distribution channel.  A
	     higher limit gives	lower latency and higher throughput at the ex-
	     pense of higher memory use.

	   +zdntgc time:
	     Sets  the	delayed	 node  table  garbage  collection  time	  (de-
	     layed_node_table_gc) in seconds. Valid values are either infinity
	     or	an integer in the range	0-100000000. Defaults to 60.

	     Node table	entries	that are not referred linger in	the table  for
	     at	 least	the amount of time that	this parameter determines. The
	     lingering prevents	repeated deletions and insertions in  the  ta-
	     bles from occurring.

	   +zosrl limit:
	     Sets a limit on the amount	of outstanding requests	made by	a sys-
	     tem process orchestrating system wide  changes.  Valid  range  of
	     this  limit  is  [1, 134217727]. See erlang:system_flag(outstand-
	     ing_system_requests_limit,	Limit) for more	information.

ENVIRONMENT VARIABLES
	 ERL_CRASH_DUMP:
	   If the emulator needs to write a crash  dump,  the  value  of  this
	   variable is the filename of the crash dump file. If the variable is
	   not set, the	name of	the crash dump file is erl_crash.dump  in  the
	   current directory.

	 ERL_CRASH_DUMP_NICE:
	   Unix	 systems: If the emulator needs	to write a crash dump, it uses
	   the value of	this variable to set the nice value for	 the  process,
	   thus	 lowering its priority.	Valid range is 1-39 (higher values are
	   replaced with 39). The highest value, 39,  gives  the  process  the
	   lowest priority.

	 ERL_CRASH_DUMP_SECONDS:
	   Unix	 systems:  This	 variable gives	the number of seconds that the
	   emulator is allowed to spend	writing	a crash	dump. When  the	 given
	   number of seconds have elapsed, the emulator	is terminated.

	   ERL_CRASH_DUMP_SECONDS=0:
	     If	 the variable is set to	0 seconds, the runtime system does not
	     even attempt to write the crash dump file.	 It  only  terminates.
	     This  is  the  default  if	 option	 -heart	 is  passed to erl and
	     ERL_CRASH_DUMP_SECONDS is not set.

	   ERL_CRASH_DUMP_SECONDS=S:
	     If	the variable is	set to a positive value	S, wait	for S  seconds
	     to	 complete  the crash dump file and then	terminates the runtime
	     system with a SIGALRM signal.

	   ERL_CRASH_DUMP_SECONDS=-1:
	     A negative	value causes the termination of	the runtime system  to
	     wait  indefinitely	 until	the crash dump file has	been completly
	     written. This is the default if option -heart is  not  passed  to
	     erl and ERL_CRASH_DUMP_SECONDS is not set.

	   See also heart(3).

	 ERL_CRASH_DUMP_BYTES:
	   This	 variable sets the maximum size	of a crash dump	file in	bytes.
	   The crash dump will be truncated if this limit is exceeded. If  the
	   variable  is	 not set, no size limit	is enforced by default.	If the
	   variable is set to 0, the runtime system does not even  attempt  to
	   write a crash dump file.

	   Introduced in ERTS 8.1.2 (Erlang/OTP	19.2).

	 ERL_AFLAGS:
	   The	content	of this	variable is added to the beginning of the com-
	   mand	line for erl.

	   Flag	-extra is treated in a special way. Its	scope ends at the  end
	   of  the environment variable	content. Arguments following an	-extra
	   flag	are moved on the command line into section  -extra,  that  is,
	   the end of the command line following an -extra flag.

	 ERL_ZFLAGS and	ERL_FLAGS:
	   The	content	of these variables are added to	the end	of the command
	   line	for erl.

	   Flag	-extra is treated in a special way. Its	scope ends at the  end
	   of  the environment variable	content. Arguments following an	-extra
	   flag	are moved on the command line into section  -extra,  that  is,
	   the end of the command line following an -extra flag.

	 ERL_LIBS:
	   Contains  a	list  of  additional library directories that the code
	   server searches for applications and	adds to	 the  code  path;  see
	   code(3).

	 ERL_EPMD_ADDRESS:
	   Can be set to a comma-separated list	of IP addresses, in which case
	   the epmd daemon listens only	on the specified  address(es)  and  on
	   the	loopback  address (which is implicitly added to	the list if it
	   has not been	specified).

	 ERL_EPMD_PORT:
	   Can contain the port	number to use when  communicating  with	 epmd.
	   The	default	port works fine	in most	cases. A different port	can be
	   specified to	allow nodes of independent clusters to co-exist	on the
	   same	 host. All nodes in a cluster must use the same	epmd port num-
	   ber.

SIGNALS
       On Unix systems,	the Erlang runtime will	interpret two  types  of  sig-
       nals.

	 SIGUSR1:
	   A SIGUSR1 signal forces a crash dump.

	 SIGTERM:
	   A  SIGTERM will produce a stop message to the init process. This is
	   equivalent to a init:stop/0 call.

	   Introduced in ERTS 8.3 (Erlang/OTP 19.3)

       The signal SIGUSR2 is reserved for internal usage. No other signals are
       handled.

CONFIGURATION
       The  standard  Erlang/OTP  system can be	reconfigured to	change the de-
       fault behavior on startup.

	 The .erlang startup file:
	   When	Erlang/OTP is started, the system searches for	a  file	 named
	   .erlang in the user's home directory.

	   If  an .erlang file is found, it is assumed to contain valid	Erlang
	   expressions.	These expressions are evaluated	as if they were	 input
	   to the shell.

	   A typical .erlang file contains a set of search paths, for example:

	 io:format("executing user profile in HOME/.erlang\n",[]).
	 code:add_path("/home/calvin/test/ebin").
	 code:add_path("/home/hobbes/bigappl-1.2/ebin").
	 io:format(".erlang rc finished\n",[]).

	 user_default and shell_default:
	   Functions  in  the shell that are not prefixed by a module name are
	   assumed to be functional objects (funs), built-in functions (BIFs),
	   or belong to	the module user_default	or shell_default.

	   To include private shell commands, define them in a module user_de-
	   fault and add the following argument	as the first line in the  .er-
	   lang	file:

	 code:load_abs("..../user_default").

	 erl:
	   If  the  contents  of  .erlang are changed and a private version of
	   user_default	is defined, the	Erlang/OTP environment can be  custom-
	   ized.  More	powerful changes can be	made by	supplying command-line
	   arguments in	the startup script  erl.  For  more  information,  see
	   init(3).

SEE ALSO
       epmd(1),	 erl_prim_loader(3),  erts_alloc(3),  init(3), application(3),
       auth(3),	code(3), erl_boot_server(3), heart(3), net_kernel(3), make(3)

Ericsson AB			   erts	12.2				erl(1)

NAME | DESCRIPTION | EXPORTS | FLAGS | EMULATOR FLAGS | ENVIRONMENT VARIABLES | SIGNALS | CONFIGURATION | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=erl&sektion=1&manpath=FreeBSD+13.1-RELEASE+and+Ports>

home | help