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

ENVIRONMENT VARIABLES

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

SIGNALS

1391       On  Unix  systems,  the Erlang runtime will interpret two types of sig‐
1392       nals.
1393
1394         SIGUSR1:
1395           A SIGUSR1 signal forces a crash dump.
1396
1397         SIGTERM:
1398           A SIGTERM will produce a stop message to the init process. This  is
1399           equivalent to a init:stop/0 call.
1400
1401           Introduced in ERTS 8.3 (Erlang/OTP 19.3)
1402
1403       The signal SIGUSR2 is reserved for internal usage. No other signals are
1404       handled.
1405

CONFIGURATION

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

SEE ALSO

1444       epmd(1), erl_prim_loader(3),  erts_alloc(3),  init(3),  application(3),
1445       auth(3), code(3), erl_boot_server(3), heart(3), net_kernel(3), make(3)
1446
1447
1448
1449Ericsson AB                       erts 10.7.1                           erl(1)
Impressum