1erl(1)                           User Commands                          erl(1)
2
3
4

NAME

6       erl - The Erlang emulator.
7

DESCRIPTION

9       The erl program starts an Erlang runtime system. The exact details (for
10       example, whether erl is a script or a program and which other  programs
11       it calls) are system-dependent.
12
13       Windows users probably want to use the werl program instead, which runs
14       in its own window with scrollbars and  supports  command-line  editing.
15       The  erl  program on Windows provides no line editing in its shell, and
16       on Windows 95 there is no way to scroll back to text that has  scrolled
17       off  the screen. The erl program must be used, however, in pipelines or
18       if you want to redirect standard input or output.
19
20   Note:
21       As from ERTS 5.9 (Erlang/OTP R15B) the runtime system does  by  default
22       not  bind  schedulers  to logical processors. For more information, see
23       system flag +sbt.
24
25

EXPORTS

27       erl <arguments>
28
29              Starts an Erlang runtime system.
30
31              The arguments can be divided into  emulator  flags,  flags,  and
32              plain arguments:
33
34                * Any  argument starting with character + is interpreted as an
35                  emulator flag.
36
37                  As indicated by the name, emulator flags control the  behav‐
38                  ior of the emulator.
39
40                * Any  argument  starting  with character - (hyphen) is inter‐
41                  preted as a flag, which is to be passed to the  Erlang  part
42                  of  the runtime system, more specifically to the init system
43                  process, see init(3).
44
45                  The init process itself interprets some of these flags,  the
46                  init  flags.  It  also  stores any remaining flags, the user
47                  flags. The latter can be retrieved by calling init:get_argu‐
48                  ment/1.
49
50                  A  small  number  of "-" flags exist, which now actually are
51                  emulator flags, see the description below.
52
53                * Plain arguments are not interpreted in  any  way.  They  are
54                  also  stored  by  the  init  process and can be retrieved by
55                  calling  init:get_plain_arguments/0.  Plain  arguments   can
56                  occur  before  the first flag, or after a -- flag. Also, the
57                  -extra flag causes everything that follows to  become  plain
58                  arguments.
59
60              Examples:
61
62              % erl +W w -sname arnie +R 9 -s my_init -extra +bertie
63              (arnie@host)1> init:get_argument(sname).
64              {ok,[["arnie"]]}
65              (arnie@host)2> init:get_plain_arguments().
66              ["+bertie"]
67
68              Here  +W  w  and  +R 9 are emulator flags. -s my_init is an init
69              flag, interpreted by init. -sname arnie is a user  flag,  stored
70              by init. It is read by Kernel and causes the Erlang runtime sys‐
71              tem to become  distributed.  Finally,  everything  after  -extra
72              (that is, +bertie) is considered as plain arguments.
73
74              % erl -myflag 1
75              1> init:get_argument(myflag).
76              {ok,[["1"]]}
77              2> init:get_plain_arguments().
78              []
79
80              Here the user flag -myflag 1 is passed to and stored by the init
81              process. It is a user-defined  flag,  presumably  used  by  some
82              user-defined application.
83

FLAGS

85       In the following list, init flags are marked "(init flag)". Unless oth‐
86       erwise specified, all other flags are user flags, for which the  values
87       can  be  retrieved by calling init:get_argument/1. Notice that the list
88       of user flags is not exhaustive, there can be more application-specific
89       flags that instead are described in the corresponding application docu‐
90       mentation.
91
92         -- (init flag):
93           Everything following -- up to the next flag  (-flag  or  +flag)  is
94           considered   plain   arguments   and   can   be   retrieved   using
95           init:get_plain_arguments/0.
96
97         -Application Par Val:
98           Sets the application configuration parameter Par to the  value  Val
99           for the application Application; see app(4) and application(3).
100
101         -args_file FileName:
102           Command-line  arguments  are read from the file FileName. The argu‐
103           ments read from the file replace flag '-args_file FileName' on  the
104           resulting command line.
105
106           The  file  FileName is to be a plain text file and can contain com‐
107           ments and command-line arguments. A comment begins with a # charac‐
108           ter  and  continues until the next end of line character. Backslash
109           (\\) is used  as  quoting  character.  All  command-line  arguments
110           accepted  by  erl  are  allowed,  also flag -args_file FileName. Be
111           careful not to cause circular dependencies between files containing
112           flag -args_file, though.
113
114           The  flag  -extra  is treated in special way. Its scope ends at the
115           end of the file. Arguments following an -extra flag  are  moved  on
116           the  command  line into the -extra section, that is, the end of the
117           command line following after an -extra flag.
118
119         -async_shell_start:
120           The initial Erlang shell does not read user input until the  system
121           boot  procedure has been completed (Erlang/OTP 5.4 and later). This
122           flag disables the start synchronization feature and lets the  shell
123           start in parallel with the rest of the system.
124
125         -boot File:
126           Specifies  the  name  of the boot file, File.boot, which is used to
127           start the system; see init(3). Unless  File  contains  an  absolute
128           path,  the  system  searches  for  File.boot  in  the  current  and
129           $ROOT/bin directories.
130
131           Defaults to $ROOT/bin/start.boot.
132
133         -boot_var Var Dir:
134           If the boot script contains a path variable Var other  than  $ROOT,
135           this  variable  is  expanded  to  Dir.  Used  when applications are
136           installed  in  another   directory   than   $ROOT/lib;   see   sys‐
137           tools:make_script/1,2 in SASL.
138
139         -code_path_cache:
140           Enables the code path cache of the code server; see code(3).
141
142         -compile Mod1 Mod2 ...:
143           Compiles  the  specified modules and then terminates (with non-zero
144           exit code if the compilation of some file did not succeed). Implies
145           -noinput.
146
147           Not recommended; use erlc instead.
148
149         -config Config:
150           Specifies the name of a configuration file, Config.config, which is
151           used to configure applications; see app(4) and application(3).
152
153         -connect_all false:
154           If this flag is present, global does not maintain a fully connected
155           network of distributed Erlang nodes, and then global name registra‐
156           tion cannot be used; see global(3).
157
158         -cookie Cookie:
159           Obsolete flag without any effect and common misspelling  for  -set‐
160           cookie. Use -setcookie instead.
161
162         -detached:
163           Starts  the Erlang runtime system detached from the system console.
164           Useful for  running  daemons  and  backgrounds  processes.  Implies
165           -noinput.
166
167         -emu_args:
168           Useful for debugging. Prints the arguments sent to the emulator.
169
170         -emu_type Type:
171           Start  an  emulator  of a different type. For example, to start the
172           lock-counter emualator, use  -emu_type  lcnt.  (The  emulator  must
173           already be built. Use the configure option --enable-lock-counter to
174           build the lock-counter emulator.)
175
176         -env Variable Value:
177           Sets the host OS environment variable Variable to the  value  Value
178           for the Erlang runtime system. Example:
179
180         % erl -env DISPLAY gin:0
181
182           In  this example, an Erlang runtime system is started with environ‐
183           ment variable DISPLAY set to gin:0.
184
185         -epmd_module Module (init flag):
186           Configures the module responsible to communicate to epmd.  Defaults
187           to erl_epmd.
188
189         -eval Expr (init flag):
190           Makes init evaluate the expression Expr; see init(3).
191
192         -extra (init flag):
193           Everything  following  -extra is considered plain arguments and can
194           be retrieved using init:get_plain_arguments/0.
195
196         -heart:
197           Starts heartbeat monitoring  of  the  Erlang  runtime  system;  see
198           heart(3).
199
200         -hidden:
201           Starts  the Erlang runtime system as a hidden node, if it is run as
202           a distributed node. Hidden nodes always  establish  hidden  connec‐
203           tions to all other nodes except for nodes in the same global group.
204           Hidden connections are not published on any of the connected nodes,
205           that  is,  none  of the connected nodes are part of the result from
206           nodes/0  on  the  other  node.  See  also  hidden  global   groups;
207           global_group(3).
208
209         -hosts Hosts:
210           Specifies  the  IP  addresses  for  the  hosts on which Erlang boot
211           servers are running, see erl_boot_server(3). This flag is mandatory
212           if flag -loader inet is present.
213
214           The IP addresses must be specified in the standard form (four deci‐
215           mal numbers separated by  periods,  for  example,  "150.236.20.74".
216           Hosts names are not acceptable, but a broadcast address (preferably
217           limited to the local network) is.
218
219         -id Id:
220           Specifies the identity of the Erlang runtime system. If it  is  run
221           as  a  distributed  node, Id must be identical to the name supplied
222           together with flag -sname or -name.
223
224         -init_debug:
225           Makes init write some debug information while interpreting the boot
226           script.
227
228         -instr (emulator flag):
229           Selects  an instrumented Erlang runtime system (virtual machine) to
230           run, instead of the ordinary one. When running an instrumented run‐
231           time  system, some resource usage data can be obtained and analyzed
232           using the instrument module. Functionally, it behaves exactly  like
233           an ordinary Erlang runtime system.
234
235         -loader Loader:
236           Specifies the method used by erl_prim_loader to load Erlang modules
237           into the system; see erl_prim_loader(3).  Two  Loader  methods  are
238           supported:
239
240           * efile,  which  means  use  the  local  file  system,  this is the
241             default.
242
243           * inet, which means use a boot server on another machine. The flags
244             -id, -hosts and -setcookie must also be specified.
245
246           If  Loader is something else, the user-supplied Loader port program
247           is started.
248
249         -make:
250           Makes the Erlang runtime system invoke make:all()  in  the  current
251           working  directory  and then terminate; see make(3). Implies -noin‐
252           put.
253
254         -man Module:
255           Displays the manual page for the Erlang module  Module.  Only  sup‐
256           ported on Unix.
257
258         -mode interactive | embedded:
259           Modules  are auto loaded when they are first referenced if the run‐
260           time system runs in interactive mode,  which  is  the  default.  In
261           embedded  mode  modules  are  not auto loaded. The latter is recom‐
262           mended when the boot script preloads all modules, as conventionally
263           happens in OTP releases. See code(3).
264
265         -name Name:
266           Makes  the Erlang runtime system into a distributed node. This flag
267           invokes all network servers necessary for a node to become distrib‐
268           uted;  see  net_kernel(3). It is also ensured that epmd runs on the
269           current  host  before  Erlang  is  started;  see  epmd(1).and   the
270           -start_epmd option.
271
272           The  node name will be Name@Host, where Host is the fully qualified
273           host name of the current host. For short  names,  use  flag  -sname
274           instead.
275
276     Warning:
277         Starting  a  distributed  node  without  also  specifying -proto_dist
278         inet_tls will expose the node to attacks that may give  the  attacker
279         complete  access to the node and in extension the cluster. When using
280         un-secure distributed nodes, make sure that the network is configured
281         to keep potential attackers out.
282
283
284         -noinput:
285           Ensures  that  the  Erlang  runtime  system never tries to read any
286           input. Implies -noshell.
287
288         -noshell:
289           Starts an Erlang runtime system with no shell. This flag  makes  it
290           possible  to  have  the  Erlang  runtime system as a component in a
291           series of Unix pipes.
292
293         -nostick:
294           Disables the sticky directory facility of the Erlang  code  server;
295           see code(3).
296
297         -oldshell:
298           Invokes the old Erlang shell from Erlang/OTP 3.3. The old shell can
299           still be used.
300
301         -pa Dir1 Dir2 ...:
302           Adds the specified directories to the beginning of the  code  path,
303           similar  to  code:add_pathsa/1.  Note  that  the order of the given
304           directories will be reversed in the resulting path.
305
306           As an  alternative  to  -pa,  if  several  directories  are  to  be
307           prepended to the code path and the directories have a common parent
308           directory, that parent directory can be  specified  in  environment
309           variable ERL_LIBS; see code(3).
310
311         -pz Dir1 Dir2 ...:
312           Adds the specified directories to the end of the code path, similar
313           to code:add_pathsz/1; see code(3).
314
315         -path Dir1 Dir2 ...:
316           Replaces the path specified in the boot script; see script(4).
317
318         -proto_dist Proto:
319
320
321           Specifies a protocol for Erlang distribution:
322
323           inet_tcp:
324             TCP over IPv4 (the default)
325
326           inet_tls:
327             Distribution over TLS/SSL, See the  Using SSL for Erlang  Distri‐
328             bution User's Guide for details on how to setup a secure distrib‐
329             uted node.
330
331           inet6_tcp:
332             TCP over IPv6
333
334           For example, to start up IPv6 distributed nodes:
335
336         % erl -name test@ipv6node.example.com -proto_dist inet6_tcp
337
338         -remsh Node:
339           Starts Erlang with a  remote  shell  connected  to  Node.  Requires
340           either  -name  or  -sname  to  be given. If Node does not contain a
341           hostname, one is automatically taken from -name or -sname
342
343         -rsh Program:
344           Specifies an alternative to ssh for starting  a  slave  node  on  a
345           remote host; see slave(3).
346
347         -run Mod [Func [Arg1, Arg2, ...]] (init flag):
348           Makes  init call the specified function. Func defaults to start. If
349           no arguments are provided, the function is assumed to be  of  arity
350           0.  Otherwise  it  is  assumed  to  be  of arity 1, taking the list
351           [Arg1,Arg2,...] as argument. All arguments are passed  as  strings.
352           See init(3).
353
354         -s Mod [Func [Arg1, Arg2, ...]] (init flag):
355           Makes  init call the specified function. Func defaults to start. If
356           no arguments are provided, the function is assumed to be  of  arity
357           0.  Otherwise  it  is  assumed  to  be  of arity 1, taking the list
358           [Arg1,Arg2,...] as argument. All arguments are passed as atoms. See
359           init(3).
360
361         -setcookie Cookie:
362           Sets    the   magic   cookie   of   the   node   to   Cookie;   see
363           erlang:set_cookie/2.
364
365         -shutdown_time Time:
366           Specifies how long time  (in  milliseconds)  the  init  process  is
367           allowed  to  spend  shutting  down the system. If Time milliseconds
368           have elapsed, all processes still existing are killed. Defaults  to
369           infinity.
370
371         -sname Name:
372           Makes the Erlang runtime system into a distributed node, similar to
373           -name, but the host name portion of the node name Name@Host will be
374           the short name, not fully qualified.
375
376           This  is  sometimes  the  only way to run distributed Erlang if the
377           Domain Name System (DNS) is not running. No communication can exist
378           between  nodes running with flag -sname and those running with flag
379           -name, as node names must be unique in distributed Erlang systems.
380
381     Warning:
382         Starting a  distributed  node  without  also  specifying  -proto_dist
383         inet_tls  will  expose the node to attacks that may give the attacker
384         complete access to the node and in extension the cluster. When  using
385         un-secure distributed nodes, make sure that the network is configured
386         to keep potential attackers out.
387
388
389         -start_epmd true | false:
390           Specifies whether Erlang should start epmd on startup.  By  default
391           this is true, but if you prefer to start epmd manually, set this to
392           false.
393
394           This only applies if Erlang is started as a distributed node,  i.e.
395           if  -name  or  -sname  is specified. Otherwise, epmd is not started
396           even if -start_epmd true is given.
397
398           Note that a distributed node will fail to start if epmd is not run‐
399           ning.
400
401         -version (emulator flag):
402           Makes the emulator print its version number. The same as erl +V.
403

EMULATOR FLAGS

405       erl  invokes  the code for the Erlang emulator (virtual machine), which
406       supports the following flags:
407
408         +a size:
409           Suggested stack size, in kilowords, for threads in the async thread
410           pool. Valid range is 16-8192 kilowords. The default suggested stack
411           size is 16 kilowords, that is, 64 kilobyte on 32-bit architectures.
412           This small default size has been chosen because the number of async
413           threads can be large. The default size is enough for drivers deliv‐
414           ered  with  Erlang/OTP,  but  might  not  be large enough for other
415           dynamically linked-in drivers that use the driver_async() function‐
416           ality.  Notice  that  the value passed is only a suggestion, and it
417           can even be ignored on some platforms.
418
419         +A size:
420           Sets the number of threads in async thread  pool.  Valid  range  is
421           0-1024. Defaults to 1.
422
423         +B [c | d | i]:
424           Option c makes Ctrl-C interrupt the current shell instead of invok‐
425           ing the emulator break handler. Option d  (same  as  specifying  +B
426           without an extra option) disables the break handler. Option i makes
427           the emulator ignore any break signal.
428
429           If option c is used with oldshell on Unix, Ctrl-C will restart  the
430           shell process rather than interrupt it.
431
432           Notice  that on Windows, this flag is only applicable for werl, not
433           erl (oldshell). Notice also that  Ctrl-Break  is  used  instead  of
434           Ctrl-C on Windows.
435
436         +c true | false:
437           Enables or disables time correction:
438
439           true:
440             Enables  time  correction. This is the default if time correction
441             is supported on the specific platform.
442
443           false:
444             Disables time correction.
445
446           For backward compatibility, the boolean value can be omitted.  This
447           is interpreted as +c false.
448
449         +C no_time_warp | single_time_warp | multi_time_warp:
450           Sets time warp mode:
451
452           no_time_warp:
453              No time warp mode (the default)
454
455           single_time_warp:
456              Single time warp mode
457
458           multi_time_warp:
459              Multi-time warp mode
460
461         +d:
462           If  the emulator detects an internal error (or runs out of memory),
463           it, by default, generates both a crash dump and a  core  dump.  The
464           core  dump  is,  however, not very useful as the content of process
465           heaps is destroyed by the crash dump generation.
466
467           Option +d instructs the emulator to produce only a core dump and no
468           crash dump if an internal error is detected.
469
470           Calling erlang:halt/1 with a string argument still produces a crash
471           dump. On Unix systems, sending an emulator process a SIGUSR1 signal
472           also forces a crash dump.
473
474         +rg DecentralizedCounterGroupsLimit:
475           Limits  the  number  of decentralized counter groups used by decen‐
476           tralized counters optimized for update  operations  in  the  Erlang
477           runtime system. By default, the limit is 256.
478
479           When  the  number of schedulers is less than or equal to the limit,
480           each scheduler has its own group. When the number of schedulers  is
481           larger  than  the  groups  limit,  schedulers  share groups. Shared
482           groups degrade the performance for  updating  counters  while  many
483           reader groups degrade the performance for reading counters. So, the
484           limit is a tradeoff between performance for update  operations  and
485           performance  for  read  operations. Each group consumes 64 bytes in
486           each counter.
487
488           Notice that a runtime system  using  decentralized  counter  groups
489           benefits  from  binding  schedulers  to  logical processors, as the
490           groups are distributed better between schedulers with this option.
491
492           This option only affects decentralized counters used for the  coun‐
493           ters  that are keeping track of the memory consumption and the num‐
494           ber of terms in ETS tables of type ordered_set with the  write_con‐
495           currency option activated.
496
497         +e Number:
498           Sets  the  maximum  number  of  ETS tables. This limit is partially
499           obsolete.
500
501         +ec:
502           Forces option compressed on all ETS tables. Only intended for  test
503           and evaluation.
504
505         +fnl:
506           The  virtual  machine  works  with filenames as if they are encoded
507           using the ISO Latin-1 encoding, disallowing Unicode characters with
508           code points > 255.
509
510           For  more  information about Unicode filenames, see section Unicode
511           Filenames in the STDLIB User's Guide. Notice that this  value  also
512           applies  to  command-line parameters and environment variables (see
513           section  Unicode in Environment and Parameters in the STDLIB User's
514           Guide).
515
516         +fnu[{w|i|e}]:
517           The  virtual  machine  works  with filenames as if they are encoded
518           using UTF-8 (or some other system-specific Unicode encoding).  This
519           is  the default on operating systems that enforce Unicode encoding,
520           that is, Windows and MacOS X.
521
522           The +fnu switch can be followed by  w,  i,  or  e  to  control  how
523           wrongly encoded filenames are to be reported:
524
525           * w  means  that  a  warning is sent to the error_logger whenever a
526             wrongly encoded filename is "skipped" in directory listings. This
527             is the default.
528
529           * i  means  that  those  wrongly  encoded  filenames  are  silently
530             ignored.
531
532           * e means that the API function returns an error whenever a wrongly
533             encoded filename (or directory name) is encountered.
534
535           Notice  that  file:read_link/1  always returns an error if the link
536           points to an invalid filename.
537
538           For more information about Unicode filenames, see  section  Unicode
539           Filenames  in  the STDLIB User's Guide. Notice that this value also
540           applies to command-line parameters and environment  variables  (see
541           section  Unicode in Environment and Parameters in the STDLIB User's
542           Guide).
543
544         +fna[{w|i|e}]:
545           Selection between +fnl and +fnu is done based on the current locale
546           settings  in  the OS. This means that if you have set your terminal
547           for UTF-8 encoding, the filesystem is  expected  to  use  the  same
548           encoding  for  filenames. This is default on all operating systems,
549           except MacOS X and Windows.
550
551           The +fna switch can be followed by w, i, or e. This has  effect  if
552           the  locale settings cause the behavior of +fnu to be selected; see
553           the description of +fnu above. If the  locale  settings  cause  the
554           behavior of +fnl to be selected, then w, i, or e have no effect.
555
556           For  more  information about Unicode filenames, see section Unicode
557           Filenames in the STDLIB User's Guide. Notice that this  value  also
558           applies  to  command-line parameters and environment variables (see
559           section  Unicode in Environment and Parameters in the STDLIB User's
560           Guide).
561
562         +hms Size:
563           Sets the default heap size of processes to the size Size.
564
565         +hmbs Size:
566           Sets  the default binary virtual heap size of processes to the size
567           Size.
568
569         +hmax Size:
570           Sets the default maximum heap size of processes to the  size  Size.
571           Defaults  to  0, which means that no maximum heap size is used. For
572           more information, see process_flag(max_heap_size, MaxHeapSize).
573
574         +hmaxel true|false:
575           Sets whether to send an error logger message or not  for  processes
576           reaching the maximum heap size. Defaults to true. For more informa‐
577           tion, see process_flag(max_heap_size, MaxHeapSize).
578
579         +hmaxk true|false:
580           Sets whether to kill processes reaching the maximum  heap  size  or
581           not.    Default    to    true.    For    more    information,   see
582           process_flag(max_heap_size, MaxHeapSize).
583
584         +hpds Size:
585           Sets the initial process dictionary size of processes to  the  size
586           Size.
587
588         +hmqd off_heap|on_heap:
589           Sets   the  default  value  for  process  flag  message_queue_data.
590           Defaults to on_heap. If +hmqd is not passed, on_heap  will  be  the
591           default. For more information, see process_flag(message_queue_data,
592           MQD).
593
594         +IOp PollSets:
595           Sets the number of IO pollsets to use when polling  for  I/O.  This
596           option is only used on platforms that support concurrent updates of
597           a pollset, otherwise the same number of pollsets  are  used  as  IO
598           poll threads. The default is 1.
599
600         +IOt PollThreads:
601           Sets the number of IO poll threads to use when polling for I/O. The
602           maximum number of poll threads allowed is 1024. The default is 1.
603
604           A good way to check if more IO poll threads are needed  is  to  use
605           microstate  accounting  and see what the load of the IO poll thread
606           is. If it is high it could be a good idea to add more threads.
607
608         +IOPp PollSetsPercentage:
609           Similar to +IOp but uses  percentages  to  set  the  number  of  IO
610           pollsets to create, based on the number of poll threads configured.
611           If both +IOPp and +IOp are used, +IOPp is ignored.
612
613         +IOPt PollThreadsPercentage:
614           Similar to +IOt but uses percentages to set the number of  IO  poll
615           threads to create, based on the number of schedulers configured. If
616           both +IOPt and +IOt are used, +IOPt is ignored.
617
618         +l:
619           Enables autoload  tracing,  displaying  information  while  loading
620           code.
621
622         +L:
623           Prevents  loading  information about source filenames and line num‐
624           bers. This saves some memory, but exceptions do not contain  infor‐
625           mation about the filenames and line numbers.
626
627         +MFlag Value:
628           Memory   allocator-specific   flags.   For  more  information,  see
629           erts_alloc(3).
630
631         +pc Range:
632           Sets the range of characters that the system considers printable in
633           heuristic  detection  of strings. This typically affects the shell,
634           debugger, and io:format functions (when ~tp is used in  the  format
635           string).
636
637           Two values are supported for Range:
638
639           latin1:
640             The default. Only characters in the ISO Latin-1 range can be con‐
641             sidered printable. This means that a character with a code  point
642             >  255  is  never  considered printable and that lists containing
643             such characters are displayed as lists of  integers  rather  than
644             text strings by tools.
645
646           unicode:
647             All  printable Unicode characters are considered when determining
648             if a list of integers is to be displayed in string  syntax.  This
649             can  give  unexpected results if, for example, your font does not
650             cover all Unicode characters.
651
652           See also io:printable_range/0 in STDLIB.
653
654         +P Number:
655           Sets the maximum number of simultaneously  existing  processes  for
656           this  system if a Number is passed as value. Valid range for Number
657           is [1024-134217727]
658
659           NOTE: The actual maximum chosen may be much larger than the  Number
660           passed. Currently the runtime system often, but not always, chooses
661           a value that is a power of 2. This might, however,  be  changed  in
662           the  future.  The  actual  value  chosen  can be checked by calling
663           erlang:system_info(process_limit).
664
665           The default value is 262144
666
667         +Q Number:
668           Sets the maximum number of simultaneously existing ports  for  this
669           system  if  a  Number is passed as value. Valid range for Number is
670           [1024-134217727]
671
672           NOTE: The actual maximum chosen may be much larger than the  actual
673           Number  passed. Currently the runtime system often, but not always,
674           chooses a value that is a power  of  2.  This  might,  however,  be
675           changed  in  the  future. The actual value chosen can be checked by
676           calling erlang:system_info(port_limit).
677
678           The default value used is normally 65536. However, if  the  runtime
679           system is able to determine maximum amount of file descriptors that
680           it is allowed to open and this value is larger than 65536, the cho‐
681           sen  value will increased to a value larger or equal to the maximum
682           amount of file descriptors that can be opened.
683
684           On Windows the default value is set to 8196 because the  normal  OS
685           limitations are set higher than most machines can handle.
686
687         +R ReleaseNumber:
688           Sets the compatibility mode.
689
690           The  distribution  mechanism is not backward compatible by default.
691           This flag sets the emulator in compatibility mode with  an  earlier
692           Erlang/OTP release ReleaseNumber. The release number must be in the
693           range <current release>-2..<current release>. This limits the  emu‐
694           lator,  making  it possible for it to communicate with Erlang nodes
695           (as well as C- and Java nodes) running that earlier release.
696
697     Note:
698         Ensure that all nodes (Erlang-, C-, and Java nodes) of a  distributed
699         Erlang  system is of the same Erlang/OTP release, or from two differ‐
700         ent Erlang/OTP releases X and Y, where all Y nodes have compatibility
701         mode X.
702
703
704         +r:
705           Forces ETS memory block to be moved on realloc.
706
707         +rg ReaderGroupsLimit:
708           Limits  the  number of reader groups used by read/write locks opti‐
709           mized for read operations in the Erlang runtime system. By  default
710           the reader groups limit is 64.
711
712           When  the  number of schedulers is less than or equal to the reader
713           groups limit, each scheduler has its own  reader  group.  When  the
714           number of schedulers is larger than the reader groups limit, sched‐
715           ulers share reader groups. Shared reader groups degrade  read  lock
716           and  read unlock performance while many reader groups degrade write
717           lock performance. So, the limit is a tradeoff  between  performance
718           for  read  operations  and  performance  for write operations. Each
719           reader group consumes 64 byte in each read/write lock.
720
721           Notice that a runtime system using shared  reader  groups  benefits
722           from binding schedulers to logical processors, as the reader groups
723           are distributed better between schedulers.
724
725         +S Schedulers:SchedulerOnline:
726           Sets the number  of  scheduler  threads  to  create  and  scheduler
727           threads  to set online. The maximum for both values is 1024. If the
728           Erlang runtime system is able to determine the  number  of  logical
729           processors  configured and logical processors available, Schedulers
730           defaults to logical  processors  configured,  and  SchedulersOnline
731           defaults  to  logical  processors  available; otherwise the default
732           values are 1. Schedulers can be omitted if :SchedulerOnline is  not
733           and  conversely.  The number of schedulers online can be changed at
734           runtime through erlang:system_flag(schedulers_online, SchedulersOn‐
735           line).
736
737           If  Schedulers  or SchedulersOnline is specified as a negative num‐
738           ber, the value is subtracted from the  default  number  of  logical
739           processors  configured  or  logical  processors  available, respec‐
740           tively.
741
742           Specifying value 0 for Schedulers or  SchedulersOnline  resets  the
743           number  of  scheduler  threads or scheduler threads online, respec‐
744           tively, to its default value.
745
746         +SP SchedulersPercentage:SchedulersOnlinePercentage:
747           Similar to +S but uses percentages to set the number  of  scheduler
748           threads  to  create,  based  on  logical processors configured, and
749           scheduler threads to set online, based on logical processors avail‐
750           able. Specified values must be > 0. For example, +SP 50:25 sets the
751           number of scheduler threads to 50% of the logical  processors  con‐
752           figured,  and  the number of scheduler threads online to 25% of the
753           logical processors available. SchedulersPercentage can  be  omitted
754           if :SchedulersOnlinePercentage is not and conversely. The number of
755           schedulers online can be changed  at  runtime  through  erlang:sys‐
756           tem_flag(schedulers_online, SchedulersOnline).
757
758           This  option  interacts  with +S settings. For example, on a system
759           with 8 logical cores configured and 8 logical cores available,  the
760           combination  of  the  options  +S  4:4  +SP 50:25 (in either order)
761           results in 2 scheduler threads (50% of 4) and  1  scheduler  thread
762           online (25% of 4).
763
764         +SDcpu DirtyCPUSchedulers:DirtyCPUSchedulersOnline:
765           Sets  the number of dirty CPU scheduler threads to create and dirty
766           CPU scheduler threads to set online. The maximum for both values is
767           1024,  and each value is further limited by the settings for normal
768           schedulers:
769
770           * The number of dirty CPU scheduler threads created  cannot  exceed
771             the number of normal scheduler threads created.
772
773           * The  number  of  dirty CPU scheduler threads online cannot exceed
774             the number of normal scheduler threads online.
775
776           For details, see the +S and +SP. By default, the  number  of  dirty
777           CPU scheduler threads created equals the number of normal scheduler
778           threads created, and the number  of  dirty  CPU  scheduler  threads
779           online equals the number of normal scheduler threads online. Dirty‐
780           CPUSchedulers can be omitted if  :DirtyCPUSchedulersOnline  is  not
781           and  conversely.  The  number of dirty CPU schedulers online can be
782           changed  at  runtime  through   erlang:system_flag(dirty_cpu_sched‐
783           ulers_online, DirtyCPUSchedulersOnline).
784
785           The amount of dirty CPU schedulers is limited by the amount of nor‐
786           mal schedulers in order to limit the effect on processes  executing
787           on  ordinary  schedulers. If the amount of dirty CPU schedulers was
788           allowed to be unlimited, dirty CPU  bound  jobs  would  potentially
789           starve normal jobs.
790
791         +SDPcpu DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercent‐
792         age:
793           Similar to +SDcpu but uses percentages to set the number  of  dirty
794           CPU  scheduler threads to create and the number of dirty CPU sched‐
795           uler threads to set online. Specified values must be > 0. For exam‐
796           ple,  +SDPcpu  50:25 sets the number of dirty CPU scheduler threads
797           to 50% of the logical processors configured and the number of dirty
798           CPU  scheduler  threads  online  to  25%  of the logical processors
799           available. DirtyCPUSchedulersPercentage can be omitted if  :DirtyC‐
800           PUSchedulersOnlinePercentage  is  not and conversely. The number of
801           dirty CPU schedulers online  can  be  changed  at  runtime  through
802           erlang:system_flag(dirty_cpu_schedulers_online,  DirtyCPUScheduler‐
803           sOnline).
804
805           This option interacts with +SDcpu settings. For example, on a  sys‐
806           tem  with 8 logical cores configured and 8 logical cores available,
807           the combination of the options +SDcpu 4:4 +SDPcpu 50:25 (in  either
808           order)  results  in  2 dirty CPU scheduler threads (50% of 4) and 1
809           dirty CPU scheduler thread online (25% of 4).
810
811         +SDio DirtyIOSchedulers:
812           Sets the number of dirty I/O scheduler  threads  to  create.  Valid
813           range  is  0-1024.  By  default,  the number of dirty I/O scheduler
814           threads created is 10, same as the default number of threads in the
815           async thread pool.
816
817           The  amount  of dirty IO schedulers is not limited by the amount of
818           normal schedulers like the amount of  dirty  CPU  schedulers.  This
819           since  only  I/O  bound  work  is  expected to execute on dirty I/O
820           schedulers. If the user should schedule CPU bound jobs on dirty I/O
821           schedulers,  these  jobs  might  starve  ordinary jobs executing on
822           ordinary schedulers.
823
824         +sFlag Value:
825           Scheduling specific flags.
826
827           +sbt BindType:
828             Sets scheduler bind type.
829
830             Schedulers can also be bound using flag +stbt. The  only  differ‐
831             ence between these two flags is how the following errors are han‐
832             dled:
833
834             * Binding of schedulers is not supported on  the  specific  plat‐
835               form.
836
837             * No  available CPU topology. That is, the runtime system was not
838               able to detect the CPU topology  automatically,  and  no  user-
839               defined CPU topology was set.
840
841             If  any of these errors occur when +sbt has been passed, the run‐
842             time system prints an error message, and refuses to start. If any
843             of  these  errors  occur  when +stbt has been passed, the runtime
844             system silently ignores the error, and  start  up  using  unbound
845             schedulers.
846
847             Valid BindTypes:
848
849             u:
850               unbound  - Schedulers are not bound to logical processors, that
851               is, the operating system decides where  the  scheduler  threads
852               execute, and when to migrate them. This is the default.
853
854             ns:
855               no_spread  -  Schedulers  with  close scheduler identifiers are
856               bound as close as possible in hardware.
857
858             ts:
859               thread_spread - Thread refers  to  hardware  threads  (such  as
860               Intel's  hyper-threads).  Schedulers with low scheduler identi‐
861               fiers, are bound to the first hardware  thread  of  each  core,
862               then  schedulers with higher scheduler identifiers are bound to
863               the second hardware thread of each core,and so on.
864
865             ps:
866               processor_spread - Schedulers are  spread  like  thread_spread,
867               but also over physical processor chips.
868
869             s:
870               spread - Schedulers are spread as much as possible.
871
872             nnts:
873               no_node_thread_spread  -  Like  thread_spread,  but if multiple
874               Non-Uniform Memory Access (NUMA) nodes  exist,  schedulers  are
875               spread  over one NUMA node at a time, that is, all logical pro‐
876               cessors of one NUMA node are bound to schedulers in sequence.
877
878             nnps:
879               no_node_processor_spread - Like processor_spread, but if multi‐
880               ple  NUMA nodes exist, schedulers are spread over one NUMA node
881               at a time, that is, all logical processors of one NUMA node are
882               bound to schedulers in sequence.
883
884             tnnps:
885               thread_no_node_processor_spread     -    A    combination    of
886               thread_spread,  and  no_node_processor_spread.  Schedulers  are
887               spread  over hardware threads across NUMA nodes, but schedulers
888               are only spread over processors internally in one NUMA node  at
889               a time.
890
891             db:
892               default_bind  -  Binds  schedulers the default way. Defaults to
893               thread_no_node_processor_spread  (which  can  change   in   the
894               future).
895
896             Binding  of schedulers is only supported on newer Linux, Solaris,
897             FreeBSD, and Windows systems.
898
899             If no CPU topology is available when flag +sbt is  processed  and
900             BindType  is  any  other type than u, the runtime system fails to
901             start. CPU topology can be defined using flag +sct.  Notice  that
902             flag  +sct  can have to be passed before flag +sbt on the command
903             line (if no CPU topology has been automatically detected).
904
905             The runtime system does by default not bind schedulers to logical
906             processors.
907
908       Note:
909           If  the  Erlang runtime system is the only operating system process
910           that binds threads to logical processors, this improves the perfor‐
911           mance  of  the  runtime  system. However, if other operating system
912           processes (for example another Erlang  runtime  system)  also  bind
913           threads  to  logical processors, there can be a performance penalty
914           instead. This performance penalty can sometimes be severe.  If  so,
915           you are advised not to bind the schedulers.
916
917
918             How schedulers are bound matters. For example, in situations when
919             there are fewer running processes  than  schedulers  online,  the
920             runtime  system tries to migrate processes to schedulers with low
921             scheduler identifiers. The more the schedulers  are  spread  over
922             the  hardware,  the  more  resources are available to the runtime
923             system in such situations.
924
925       Note:
926           If a scheduler fails to bind, this is often silently ignored, as it
927           is  not  always  possible to verify valid logical processor identi‐
928           fiers. If an error is reported, it is reported to the error_logger.
929           If  you want to verify that the schedulers have bound as requested,
930           call erlang:system_info(scheduler_bindings).
931
932
933           +sbwt none|very_short|short|medium|long|very_long:
934             Sets scheduler busy  wait  threshold.  Defaults  to  medium.  The
935             threshold  determines  how  long schedulers are to busy wait when
936             running out of work before going to sleep.
937
938       Note:
939           This flag can be removed or  changed  at  any  time  without  prior
940           notice.
941
942
943           +sbwtdcpu none|very_short|short|medium|long|very_long:
944             As +sbwt but affects dirty CPU schedulers. Defaults to short.
945
946       Note:
947           This  flag  can  be  removed  or  changed at any time without prior
948           notice.
949
950
951           +sbwtdio none|very_short|short|medium|long|very_long:
952             As +sbwt but affects dirty IO schedulers. Defaults to short.
953
954       Note:
955           This flag can be removed or  changed  at  any  time  without  prior
956           notice.
957
958
959           +scl true|false:
960             Enables  or  disables  scheduler  compaction  of load. By default
961             scheduler compaction of load is enabled. When enabled, load  bal‐
962             ancing  strives  for  a  load  distribution, which causes as many
963             scheduler threads as possible to be fully loaded  (that  is,  not
964             run  out  of  work).  This is accomplished by migrating load (for
965             example, runnable processes) into a  smaller  set  of  schedulers
966             when  schedulers  frequently  run out of work. When disabled, the
967             frequency with which schedulers run out of work is not taken into
968             account by the load balancing logic.
969
970             +scl  false  is similar to +sub true, but +sub true also balances
971             scheduler utilization between schedulers.
972
973           +sct CpuTopology:
974
975
976             * <Id> = integer(); when 0 =< <Id> =< 65535
977
978             * <IdRange> = <Id>-<Id>
979
980             * <IdOrIdRange> = <Id> | <IdRange>
981
982             * <IdList> = <IdOrIdRange>,<IdOrIdRange> | <IdOrIdRange>
983
984             * <LogicalIds> = L<IdList>
985
986             * <ThreadIds> = T<IdList> | t<IdList>
987
988             * <CoreIds> = C<IdList> | c<IdList>
989
990             * <ProcessorIds> = P<IdList> | p<IdList>
991
992             * <NodeIds> = N<IdList> | n<IdList>
993
994             * <IdDefs>       =       <LogicalIds><ThreadIds><CoreIds><Proces‐
995               sorIds><NodeIds>         |         <LogicalIds><ThreadIds><Cor‐
996               eIds><NodeIds><ProcessorIds>
997
998             * CpuTopology = <IdDefs>:<IdDefs> | <IdDefs>
999
1000             Sets a user-defined CPU topology. The user-defined  CPU  topology
1001             overrides any automatically detected CPU topology. The CPU topol‐
1002             ogy is used when binding schedulers to logical processors.
1003
1004             Uppercase letters signify real identifiers and lowercase  letters
1005             signify  fake identifiers only used for description of the topol‐
1006             ogy. Identifiers passed as real identifiers can be  used  by  the
1007             runtime  system  when trying to access specific hardware; if they
1008             are incorrect the behavior is undefined. Faked logical CPU  iden‐
1009             tifiers  are  not  accepted, as there is no point in defining the
1010             CPU topology without real logical CPU identifiers. Thread,  core,
1011             processor,  and  node identifiers can be omitted. If omitted, the
1012             thread ID defaults to t0, the core ID defaults to c0, the proces‐
1013             sor  ID defaults to p0, and the node ID is left undefined. Either
1014             each logical processor must belong to only one NUMA node,  or  no
1015             logical processors must belong to any NUMA nodes.
1016
1017             Both increasing and decreasing <IdRange>s are allowed.
1018
1019             NUMA node identifiers are system wide. That is, each NUMA node on
1020             the system must have a unique identifier.  Processor  identifiers
1021             are also system wide. Core identifiers are processor wide. Thread
1022             identifiers are core wide.
1023
1024             The order of the identifier types implies the  hierarchy  of  the
1025             CPU topology. The valid orders are as follows:
1026
1027             * <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>,   that
1028               is, thread is part of a core that is part of a processor, which
1029               is part of a NUMA node.
1030
1031             * <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>,   that
1032               is, thread is part of a core that is part of a NUMA node, which
1033               is part of a processor.
1034
1035             A  CPU  topology can consist of both processor external, and pro‐
1036             cessor internal NUMA nodes as  long  as  each  logical  processor
1037             belongs  to only one NUMA node. If <ProcessorIds> is omitted, its
1038             default position is before <NodeIds>. That  is,  the  default  is
1039             processor external NUMA nodes.
1040
1041             If a list of identifiers is used in an <IdDefs>:
1042
1043             * <LogicalIds> must be a list of identifiers.
1044
1045             * At  least  one  other identifier type besides <LogicalIds> must
1046               also have a list of identifiers.
1047
1048             * All lists of identifiers must produce the same number of  iden‐
1049               tifiers.
1050
1051             A  simple  example. A single quad core processor can be described
1052             as follows:
1053
1054           % erl +sct L0-3c0-3
1055           1> erlang:system_info(cpu_topology).
1056           [{processor,[{core,{logical,0}},
1057                        {core,{logical,1}},
1058                        {core,{logical,2}},
1059                        {core,{logical,3}}]}]
1060
1061             A more complicated example with two quad  core  processors,  each
1062             processor  in  its own NUMA node. The ordering of logical proces‐
1063             sors is a bit weird. This to give a better example of  identifier
1064             lists:
1065
1066           % erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
1067           1> erlang:system_info(cpu_topology).
1068           [{node,[{processor,[{core,{logical,0}},
1069                               {core,{logical,1}},
1070                               {core,{logical,3}},
1071                               {core,{logical,2}}]}]},
1072            {node,[{processor,[{core,{logical,7}},
1073                               {core,{logical,4}},
1074                               {core,{logical,6}},
1075                               {core,{logical,5}}]}]}]
1076
1077             As  long  as real identifiers are correct, it is OK to pass a CPU
1078             topology that is not a correct description of the  CPU  topology.
1079             When  used  with  care this can be very useful. This to trick the
1080             emulator to bind its schedulers as you want. For example, if  you
1081             want  to run multiple Erlang runtime systems on the same machine,
1082             you want to reduce the number of schedulers used  and  manipulate
1083             the  CPU topology so that they bind to different logical CPUs. An
1084             example, with two Erlang runtime systems on a quad core machine:
1085
1086           % erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname one
1087           % erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname two
1088
1089             In this example, each runtime system  have  two  schedulers  each
1090             online, and all schedulers online will run on different cores. If
1091             we change to one scheduler online  on  one  runtime  system,  and
1092             three  schedulers online on the other, all schedulers online will
1093             still run on different cores.
1094
1095             Notice that a faked CPU topology that does not  reflect  how  the
1096             real  CPU  topology  looks like is likely to decrease the perfor‐
1097             mance of the runtime system.
1098
1099             For more information, see erlang:system_info(cpu_topology).
1100
1101           +sfwi Interval:
1102             Sets scheduler-forced wakeup interval. All run queues are scanned
1103             each  Interval  milliseconds. While there are sleeping schedulers
1104             in the system, one scheduler is  woken  for  each  non-empty  run
1105             queue  found. Interval default to 0, meaning this feature is dis‐
1106             abled.
1107
1108       Note:
1109           This feature has been introduced  as  a  temporary  workaround  for
1110           long-executing  native  code,  and  native  code that does not bump
1111           reductions properly in OTP. When these bugs  have  be  fixed,  this
1112           flag will be removed.
1113
1114
1115           +spp Bool:
1116             Sets default scheduler hint for port parallelism. If set to true,
1117             the virtual machine schedules port tasks when it improves  paral‐
1118             lelism  in the system. If set to false, the virtual machine tries
1119             to perform port  tasks  immediately,  improving  latency  at  the
1120             expense of parallelism. Default to false. The default used can be
1121             inspected in runtime by calling erlang:system_info(port_parallel‐
1122             ism).  The  default can be overridden on port creation by passing
1123             option parallelism to erlang:open_port/2.
1124
1125           +sss size:
1126             Suggested stack size, in kilowords, for scheduler threads.  Valid
1127             range  is  20-8192 kilowords. The default suggested stack size is
1128             128 kilowords.
1129
1130           +sssdcpu size:
1131             Suggested stack size,  in  kilowords,  for  dirty  CPU  scheduler
1132             threads.  Valid range is 20-8192 kilowords. The default suggested
1133             stack size is 40 kilowords.
1134
1135           +sssdio size:
1136             Suggested stack  size,  in  kilowords,  for  dirty  IO  scheduler
1137             threads.  Valid range is 20-8192 kilowords. The default suggested
1138             stack size is 40 kilowords.
1139
1140           +stbt BindType:
1141             Tries to set the scheduler bind  type.  The  same  as  flag  +sbt
1142             except  how  some  errors  are handled. For more information, see
1143             +sbt.
1144
1145           +sub true|false:
1146             Enables or disables  scheduler utilization balancing of load.  By
1147             default  scheduler  utilization balancing is disabled and instead
1148             scheduler compaction of load is enabled, which strives for a load
1149             distribution that causes as many scheduler threads as possible to
1150             be fully loaded (that is, not run out of  work).  When  scheduler
1151             utilization  balancing  is  enabled,  the system instead tries to
1152             balance scheduler utilization between schedulers. That is, strive
1153             for equal scheduler utilization on all schedulers.
1154
1155             +sub  true  is only supported on systems where the runtime system
1156             detects  and  uses  a  monotonically  increasing  high-resolution
1157             clock. On other systems, the runtime system fails to start.
1158
1159             +sub  true  implies  +scl false. The difference between +sub true
1160             and +scl false is that +scl false does not  try  to  balance  the
1161             scheduler utilization.
1162
1163           +swct very_eager|eager|medium|lazy|very_lazy:
1164             Sets  scheduler  wake cleanup threshold. Defaults to medium. Con‐
1165             trols how eager schedulers are to be requesting wakeup because of
1166             certain  cleanup  operations.  When  a lazy setting is used, more
1167             outstanding cleanup operations can be left undone while a  sched‐
1168             uler  is  idling.  When  an eager setting is used, schedulers are
1169             more frequently woken, potentially increasing CPU-utilization.
1170
1171       Note:
1172           This flag can be removed or  changed  at  any  time  without  prior
1173           notice.
1174
1175
1176           +sws default|legacy:
1177             Sets  scheduler wakeup strategy. Default strategy changed in ERTS
1178             5.10 (Erlang/OTP R16A). This strategy was known  as  proposal  in
1179             Erlang/OTP  R15. The legacy strategy was used as default from R13
1180             up to and including R15.
1181
1182       Note:
1183           This flag can be removed or  changed  at  any  time  without  prior
1184           notice.
1185
1186
1187           +swt very_low|low|medium|high|very_high:
1188             Sets  scheduler wakeup threshold. Defaults to medium. The thresh‐
1189             old determines when to wake up sleeping schedulers when more work
1190             than  can  be handled by currently awake schedulers exists. A low
1191             threshold causes earlier wakeups, and  a  high  threshold  causes
1192             later wakeups. Early wakeups distribute work over multiple sched‐
1193             ulers faster, but work does more  easily  bounce  between  sched‐
1194             ulers.
1195
1196       Note:
1197           This  flag  can  be  removed  or  changed at any time without prior
1198           notice.
1199
1200
1201           +swtdcpu very_low|low|medium|high|very_high:
1202             As +swt but affects dirty CPU schedulers. Defaults to medium.
1203
1204       Note:
1205           This flag can be removed or  changed  at  any  time  without  prior
1206           notice.
1207
1208
1209           +swtdio very_low|low|medium|high|very_high:
1210             As +swt but affects dirty IO schedulers. Defaults to medium.
1211
1212       Note:
1213           This  flag  can  be  removed  or  changed at any time without prior
1214           notice.
1215
1216
1217         +t size:
1218           Sets the maximum number of atoms the virtual  machine  can  handle.
1219           Defaults to 1,048,576.
1220
1221         +T Level:
1222           Enables  modified  timing and sets the modified timing level. Valid
1223           range is 0-9. The timing of the runtime system is changed.  A  high
1224           level usually means a greater change than a low level. Changing the
1225           timing can be very useful for finding timing-related bugs.
1226
1227           Modified timing affects the following:
1228
1229           Process spawning:
1230             A process calling spawn, spawn_link, spawn_monitor, or  spawn_opt
1231             is  scheduled  out  immediately  after  completing the call. When
1232             higher modified timing levels are used, the  caller  also  sleeps
1233             for a while after it is scheduled out.
1234
1235           Context reductions:
1236             The number of reductions a process is allowed to use before it is
1237             scheduled out is increased or reduced.
1238
1239           Input reductions:
1240             The  number  of  reductions  performed  before  checking  I/O  is
1241             increased or reduced.
1242
1243     Note:
1244         Performance  suffers  when  modified  timing is enabled. This flag is
1245         only intended for testing and debugging.
1246
1247         return_to and return_from trace messages are lost when tracing on the
1248         spawn BIFs.
1249
1250         This flag can be removed or changed at any time without prior notice.
1251
1252
1253         +v:
1254           Verbose.
1255
1256         +V:
1257           Makes the emulator print its version number.
1258
1259         +W w | i | e:
1260           Sets  the  mapping  of  warning messages for error_logger. Messages
1261           sent to the error logger using one of the warning routines  can  be
1262           mapped  to  errors  (+W e), warnings (+W w), or information reports
1263           (+W i). Defaults to warnings. The current mapping can be  retrieved
1264           using   error_logger:warning_map/0.   For   more  information,  see
1265           error_logger:warning_map/0 in Kernel.
1266
1267         +zFlag Value:
1268           Miscellaneous flags:
1269
1270           +zdbbl size:
1271             Sets the distribution buffer busy limit (dist_buf_busy_limit)  in
1272             kilobytes. Valid range is 1-2097151. Defaults to 1024.
1273
1274             A  larger  buffer  limit allows processes to buffer more outgoing
1275             messages over the distribution. When the buffer  limit  has  been
1276             reached,  sending  processes  will  be suspended until the buffer
1277             size has shrunk. The buffer limit is per distribution channel.  A
1278             higher  limit  gives  lower  latency and higher throughput at the
1279             expense of higher memory use.
1280
1281           +zdntgc time:
1282             Sets   the   delayed   node   table   garbage   collection   time
1283             (delayed_node_table_gc)  in  seconds.  Valid  values  are  either
1284             infinity or an integer in the range 0-100000000. Defaults to 60.
1285
1286             Node table entries that are not referred linger in the table  for
1287             at  least  the amount of time that this parameter determines. The
1288             lingering prevents  repeated  deletions  and  insertions  in  the
1289             tables from occurring.
1290

ENVIRONMENT VARIABLES

1292         ERL_CRASH_DUMP:
1293           If  the  emulator  needs  to  write a crash dump, the value of this
1294           variable is the filename of the crash dump file. If the variable is
1295           not  set,  the name of the crash dump file is erl_crash.dump in the
1296           current directory.
1297
1298         ERL_CRASH_DUMP_NICE:
1299           Unix systems: If the emulator needs to write a crash dump, it  uses
1300           the  value  of this variable to set the nice value for the process,
1301           thus lowering its priority. Valid range is 1-39 (higher values  are
1302           replaced  with  39).  The  highest value, 39, gives the process the
1303           lowest priority.
1304
1305         ERL_CRASH_DUMP_SECONDS:
1306           Unix systems: This variable gives the number of  seconds  that  the
1307           emulator  is  allowed to spend writing a crash dump. When the given
1308           number of seconds have elapsed, the emulator is terminated.
1309
1310           ERL_CRASH_DUMP_SECONDS=0:
1311             If the variable is set to 0 seconds, the runtime system does  not
1312             even  attempt  to  write the crash dump file. It only terminates.
1313             This is the default  if  option  -heart  is  passed  to  erl  and
1314             ERL_CRASH_DUMP_SECONDS is not set.
1315
1316           ERL_CRASH_DUMP_SECONDS=S:
1317             If  the variable is set to a positive value S, wait for S seconds
1318             to complete the crash dump file and then terminates  the  runtime
1319             system with a SIGALRM signal.
1320
1321           ERL_CRASH_DUMP_SECONDS=-1:
1322             A  negative value causes the termination of the runtime system to
1323             wait indefinitely until the crash dump file  has  been  completly
1324             written.  This  is  the default if option -heart is not passed to
1325             erl and ERL_CRASH_DUMP_SECONDS is not set.
1326
1327           See also heart(3).
1328
1329         ERL_CRASH_DUMP_BYTES:
1330           This variable sets the maximum size of a crash dump file in  bytes.
1331           The  crash dump will be truncated if this limit is exceeded. If the
1332           variable is not set, no size limit is enforced by default.  If  the
1333           variable  is  set to 0, the runtime system does not even attempt to
1334           write a crash dump file.
1335
1336           Introduced in ERTS 8.1.2 (Erlang/OTP 19.2).
1337
1338         ERL_AFLAGS:
1339           The content of this variable is added to the beginning of the  com‐
1340           mand line for erl.
1341
1342           Flag  -extra is treated in a special way. Its scope ends at the end
1343           of the environment variable content. Arguments following an  -extra
1344           flag  are  moved  on the command line into section -extra, that is,
1345           the end of the command line following an -extra flag.
1346
1347         ERL_ZFLAGS and ERL_FLAGS:
1348           The content of these variables are added to the end of the  command
1349           line for erl.
1350
1351           Flag  -extra is treated in a special way. Its scope ends at the end
1352           of the environment variable content. Arguments following an  -extra
1353           flag  are  moved  on the command line into section -extra, that is,
1354           the end of the command line following an -extra flag.
1355
1356         ERL_LIBS:
1357           Contains a list of additional library  directories  that  the  code
1358           server  searches  for  applications  and adds to the code path; see
1359           code(3).
1360
1361         ERL_EPMD_ADDRESS:
1362           Can be set to a comma-separated list of IP addresses, in which case
1363           the  epmd  daemon  listens only on the specified address(es) and on
1364           the loopback address (which is implicitly added to the list  if  it
1365           has not been specified).
1366
1367         ERL_EPMD_PORT:
1368           Can  contain  the  port number to use when communicating with epmd.
1369           The default port works fine in most cases. A different port can  be
1370           specified to allow nodes of independent clusters to co-exist on the
1371           same host. All nodes in a cluster must use the same epmd port  num‐
1372           ber.
1373

SIGNALS

1375       On  Unix  systems,  the Erlang runtime will interpret two types of sig‐
1376       nals.
1377
1378         SIGUSR1:
1379           A SIGUSR1 signal forces a crash dump.
1380
1381         SIGTERM:
1382           A SIGTERM will produce a stop message to the init process. This  is
1383           equivalent to a init:stop/0 call.
1384
1385           Introduced in ERTS 8.3 (Erlang/OTP 19.3)
1386
1387       The signal SIGUSR2 is reserved for internal usage. No other signals are
1388       handled.
1389

CONFIGURATION

1391       The standard Erlang/OTP  system  can  be  reconfigured  to  change  the
1392       default behavior on startup.
1393
1394         The .erlang startup file:
1395           When  Erlang/OTP  is  started, the system searches for a file named
1396           .erlang in the user's home directory.
1397
1398           If an .erlang file is found, it is assumed to contain valid  Erlang
1399           expressions.  These expressions are evaluated as if they were input
1400           to the shell.
1401
1402           A typical .erlang file contains a set of search paths, for example:
1403
1404         io:format("executing user profile in HOME/.erlang\n",[]).
1405         code:add_path("/home/calvin/test/ebin").
1406         code:add_path("/home/hobbes/bigappl-1.2/ebin").
1407         io:format(".erlang rc finished\n",[]).
1408
1409         user_default and shell_default:
1410           Functions in the shell that are not prefixed by a module  name  are
1411           assumed to be functional objects (funs), built-in functions (BIFs),
1412           or belong to the module user_default or shell_default.
1413
1414           To  include  private  shell  commands,  define  them  in  a  module
1415           user_default  and  add  the following argument as the first line in
1416           the .erlang file:
1417
1418         code:load_abs("..../user_default").
1419
1420         erl:
1421           If the contents of .erlang are changed and  a  private  version  of
1422           user_default  is defined, the Erlang/OTP environment can be custom‐
1423           ized. More powerful changes can be made by  supplying  command-line
1424           arguments  in  the  startup  script  erl. For more information, see
1425           init(3).
1426

SEE ALSO

1428       epmd(1), erl_prim_loader(3),  erts_alloc(3),  init(3),  application(3),
1429       auth(3), code(3), erl_boot_server(3), heart(3), net_kernel(3), make(3)
1430
1431
1432
1433Ericsson AB                       erts 10.5.6                           erl(1)
Impressum