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

FreeBSD Manual Pages

  
 
  

home | help
erlang(3)		   Erlang Module Definition		     erlang(3)

NAME
       erlang -	The Erlang BIFs.

DESCRIPTION
       By convention, most Built-In Functions (BIFs) are included in this mod-
       ule. Some of the	BIFs are viewed	more or	less as	 part  of  the	Erlang
       programming  language  and are auto-imported. Thus, it is not necessary
       to specify the module name. For example,	the calls atom_to_list(erlang)
       and erlang:atom_to_list(erlang) are identical.

       Auto-imported  BIFs  are	listed without module prefix. BIFs listed with
       module prefix are not auto-imported.

       BIFs can	fail for various reasons. All BIFs fail	with reason badarg  if
       they  are called	with arguments of an incorrect type. The other reasons
       are described in	the description	of each	individual BIF.

       Some BIFs can be	used in	guard tests and	are marked  with  "Allowed  in
       guard tests".

DATA TYPES
       ext_binary() = binary()

	      A	 binary	data object, structured	according to the Erlang	exter-
	      nal term format.

       iovec() = [binary()]

	      A	list of	binaries. This datatype	is useful to use together with
	      enif_inspect_iovec.

       message_queue_data() = off_heap | on_heap

	      See process_flag(message_queue_data, MQD).

       timestamp() =
	   {MegaSecs ::	integer() >= 0,
	    Secs :: integer() >= 0,
	    MicroSecs :: integer() >= 0}

	      See erlang:timestamp/0.

       time_unit() =
	   integer() >=	1 |
	   second |
	   millisecond |
	   microsecond |
	   nanosecond |
	   native |
	   perf_counter	|
	   deprecated_time_unit()

	      Supported	time unit representations:

		PartsPerSecond :: integer() _= 1:
		  Time	unit  expressed	in parts per second. That is, the time
		  unit equals 1/PartsPerSecond second.

		second:
		  Symbolic representation of the time unit represented by  the
		  integer 1.

		millisecond:
		  Symbolic  representation of the time unit represented	by the
		  integer 1000.

		microsecond:
		  Symbolic representation of the time unit represented by  the
		  integer 1000000.

		nanosecond:
		  Symbolic  representation of the time unit represented	by the
		  integer 1000000000.

		native:
		  Symbolic representation of the native	time unit used by  the
		  Erlang runtime system.

		  The  native time unit	is determined at runtime system	start,
		  and remains the same until the runtime system	terminates. If
		  a  runtime system is stopped and then	started	again (even on
		  the same machine), the native	time unit of the  new  runtime
		  system  instance can differ from the native time unit	of the
		  old runtime system instance.

		  One can get an approximation of  the	native	time  unit  by
		  calling erlang:convert_time_unit(1, second, native). The re-
		  sult equals the number of whole native time units  per  sec-
		  ond.	If the number of native	time units per second does not
		  add up to a whole number, the	result is rounded downwards.

	    Note:
		The value of the native	time unit gives	you more  or  less  no
		information  about the quality of time values. It sets a limit
		for the	 resolution and	for the	 precision of time values, but
		it  gives  no  information about the  accuracy of time values.
		The resolution of the native time unit and the	resolution  of
		time values can	differ significantly.

		perf_counter:
		  Symbolic representation of the performance counter time unit
		  used by the Erlang runtime system.

		  The perf_counter time	unit behaves much in the same  way  as
		  the native time unit.	That is, it can	differ between runtime
		  restarts.   To   get	 values	   of	 this	 type,	  call
		  os:perf_counter/0.

		deprecated_time_unit():
		  Deprecated  symbolic representations kept for	backwards-com-
		  patibility.

	      The time_unit/0 type can be extended. To convert time values be-
	      tween time units,	use erlang:convert_time_unit/3.

       deprecated_time_unit() =
	   seconds | milli_seconds | micro_seconds | nano_seconds

	      The  time_unit()	type  also consist of the following deprecated
	      symbolic time units:

		seconds:
		  Same as second.

		milli_seconds:
		  Same as millisecond.

		micro_seconds:
		  Same as microsecond.

		nano_seconds:
		  Same as nanosecond.

       dist_handle()

	      An opaque	handle identifing a distribution channel.

       nif_resource()

	      An opaque	handle identifing a NIF	resource object	.

EXPORTS
       abs(Float) -> float()

       abs(Int)	-> integer() >=	0

	      Types:

		 Int = integer()

	      Returns an integer or float that is  the	arithmetical  absolute
	      value of Float or	Int, for example:

	      >	abs(-3.33).
	      3.33
	      >	abs(-3).
	      3

	      Allowed in guard tests.

       erlang:adler32(Data) -> integer() >= 0

	      Types:

		 Data =	iodata()

	      Computes and returns the adler32 checksum	for Data.

       erlang:adler32(OldAdler,	Data) -> integer() >= 0

	      Types:

		 OldAdler = integer() >= 0
		 Data =	iodata()

	      Continues	computing the adler32 checksum by combining the	previ-
	      ous checksum, OldAdler, with the checksum	of Data.

	      The following code:

	      X	= erlang:adler32(Data1),
	      Y	= erlang:adler32(X,Data2).

	      assigns the same value to	Y as this:

	      Y	= erlang:adler32([Data1,Data2]).

       erlang:adler32_combine(FirstAdler, SecondAdler, SecondSize) ->
				 integer() >= 0

	      Types:

		 FirstAdler = SecondAdler = SecondSize = integer() >= 0

	      Combines two previously computed adler32 checksums. This	compu-
	      tation  requires	the  size  of  the  data object	for the	second
	      checksum to be known.

	      The following code:

	      Y	= erlang:adler32(Data1),
	      Z	= erlang:adler32(Y,Data2).

	      assigns the same value to	Z as this:

	      X	= erlang:adler32(Data1),
	      Y	= erlang:adler32(Data2),
	      Z	= erlang:adler32_combine(X,Y,iolist_size(Data2)).

       erlang:append_element(Tuple1, Term) -> Tuple2

	      Types:

		 Tuple1	= Tuple2 = tuple()
		 Term =	term()

	      Returns a	new tuple that has one element more than  Tuple1,  and
	      contains the elements in Tuple1 followed by Term as the last el-
	      ement.	Semantically	equivalent    to     list_to_tuple(tu-
	      ple_to_list(Tuple1) ++ [Term]), but much faster. Example:

	      >	erlang:append_element({one, two}, three).
	      {one,two,three}

       apply(Fun, Args)	-> term()

	      Types:

		 Fun = function()
		 Args =	[term()]

	      Calls a fun, passing the elements	in Args	as arguments.

	      If  the number of	elements in the	arguments are known at compile
	      time, the	call is	better written as Fun(Arg1, Arg2, ... ArgN).

	  Warning:
	      Earlier, Fun could also  be  specified  as  {Module,  Function},
	      equivalent  to apply(Module, Function, Args). This use is	depre-
	      cated and	will stop working in a future release.

       apply(Module, Function, Args) ->	term()

	      Types:

		 Module	= module()
		 Function = atom()
		 Args =	[term()]

	      Returns the result of applying Function in Module	to  Args.  The
	      applied  function	must be	exported from Module. The arity	of the
	      function is the length of	Args. Example:

	      >	apply(lists, reverse, [[a, b, c]]).
	      [c,b,a]
	      >	apply(erlang, atom_to_list, ['Erlang']).
	      "Erlang"

	      If the number of arguments are known at compile time,  the  call
	      is better	written	as Module:Function(Arg1, Arg2, ..., ArgN).

	      Failure: error_handler:undefined_function/3 is called if the ap-
	      plied function is	not exported. The error	handler	can  be	 rede-
	      fined (see process_flag/2). If error_handler is undefined, or if
	      the user has redefined the default error_handler so the replace-
	      ment  module  is undefined, an error with	reason undef is	gener-
	      ated.

       atom_to_binary(Atom, Encoding) -> binary()

	      Types:

		 Atom =	atom()
		 Encoding = latin1 | unicode | utf8

	      Returns a	binary corresponding to	 the  text  representation  of
	      Atom.  If	Encoding is latin1, one	byte exists for	each character
	      in the text representation. If Encoding is utf8 or unicode,  the
	      characters  are encoded using UTF-8 where	characters may require
	      multiple bytes.

	  Note:
	      As from Erlang/OTP 20, atoms can contain any  Unicode  character
	      and  atom_to_binary(Atom,	latin1)	may fail if the	text represen-
	      tation for Atom contains a Unicode character > 255.

	      Example:

	      >	atom_to_binary('Erlang', latin1).
	      <<"Erlang">>

       atom_to_list(Atom) -> string()

	      Types:

		 Atom =	atom()

	      Returns a	string corresponding to	 the  text  representation  of
	      Atom, for	example:

	      >	atom_to_list('Erlang').
	      "Erlang"

       binary_part(Subject, PosLen) -> binary()

	      Types:

		 Subject = binary()
		 PosLen	= {Start :: integer() >= 0, Length :: integer()}

	      Extracts the part	of the binary described	by PosLen.

	      Negative length can be used to extract bytes at the end of a bi-
	      nary, for	example:

	      1> Bin = <<1,2,3,4,5,6,7,8,9,10>>.
	      2> binary_part(Bin,{byte_size(Bin), -5}).
	      <<6,7,8,9,10>>

	      Failure: badarg if PosLen	in any way references outside the  bi-
	      nary.

	      Start is zero-based, that	is:

	      1> Bin = <<1,2,3>>
	      2> binary_part(Bin,{0,2}).
	      <<1,2>>

	      For details about	the PosLen semantics, see binary(3).

	      Allowed in guard tests.

       binary_part(Subject, Start, Length) -> binary()

	      Types:

		 Subject = binary()
		 Start = integer() >= 0
		 Length	= integer()

	      The same as binary_part(Subject, {Start, Length}).

	      Allowed in guard tests.

       binary_to_atom(Binary, Encoding)	-> atom()

	      Types:

		 Binary	= binary()
		 Encoding = latin1 | unicode | utf8

	      Returns  the atom	whose text representation is Binary. If	Encod-
	      ing is latin1, no	translation of bytes in	the binary is done. If
	      Encoding is utf8 or unicode, the binary must contain valid UTF-8
	      sequences.

	  Note:
	      As from Erlang/OTP 20, binary_to_atom(Binary, utf8)  is  capable
	      of  encoding  any	Unicode	character. Earlier versions would fail
	      if the binary contained Unicode characters > 255.	For  more  in-
	      formation	 about Unicode support in atoms, see the note on UTF-8
	      encoded atoms in section "External Term Format"  in  the	User's
	      Guide.

	      Examples:

	      >	binary_to_atom(<<"Erlang">>, latin1).
	      >	binary_to_atom(<<1024/utf8>>, utf8).

       binary_to_existing_atom(Binary, Encoding) -> atom()

	      Types:

		 Binary	= binary()
		 Encoding = latin1 | unicode | utf8

	      As binary_to_atom/2, but the atom	must exist.

	      Failure: badarg if the atom does not exist.

	  Note:
	      Note that	the compiler may optimize away atoms. For example, the
	      compiler will rewrite atom_to_list(some_atom) to "some_atom". If
	      that expression is the only mention of the atom some_atom	in the
	      containing module, the atom will not be created when the	module
	      is   loaded,   and   a   subsequent   call  to  binary_to_exist-
	      ing_atom(__"some_atom"__,	utf8) will fail.

       binary_to_float(Binary) -> float()

	      Types:

		 Binary	= binary()

	      Returns the float	whose text representation is Binary, for exam-
	      ple:

	      >	binary_to_float(<<"2.2017764e+0">>).
	      2.2017764

	      Failure:	badarg	if  Binary  contains a bad representation of a
	      float.

       binary_to_integer(Binary) -> integer()

	      Types:

		 Binary	= binary()

	      Returns an integer whose text representation is Binary, for  ex-
	      ample:

	      >	binary_to_integer(<<"123">>).
	      123

	      Failure:	badarg	if  Binary contains a bad representation of an
	      integer.

       binary_to_integer(Binary, Base) -> integer()

	      Types:

		 Binary	= binary()
		 Base =	2..36

	      Returns an integer whose text representation in base Base	is Bi-
	      nary, for	example:

	      >	binary_to_integer(<<"3FF">>, 16).
	      1023

	      Failure:	badarg	if  Binary contains a bad representation of an
	      integer.

       binary_to_list(Binary) -> [byte()]

	      Types:

		 Binary	= binary()

	      Returns a	list of	integers corresponding to the bytes of Binary.

       binary_to_list(Binary, Start, Stop) -> [byte()]

	      Types:

		 Binary	= binary()
		 Start = Stop =	integer() >= 1
		   1..byte_size(Binary)

	      As binary_to_list/1, but returns a list of integers  correspond-
	      ing to the bytes from position Start to position Stop in Binary.
	      The positions in the binary are numbered starting	from 1.

	  Note:
	      The one-based indexing for binaries used	by  this  function  is
	      deprecated.  New	code  is to use	binary:bin_to_list/3 in	STDLIB
	      instead. All functions in	module binary consistently  use	 zero-
	      based indexing.

       binary_to_term(Binary) -> term()

	      Types:

		 Binary	= ext_binary()

	      Returns an Erlang	term that is the result	of decoding binary ob-
	      ject Binary, which must be encoded according to the  Erlang  ex-
	      ternal term format.

	      >	Bin = term_to_binary(hello).
	      <<131,100,0,5,104,101,108,108,111>>
	      >	hello =	binary_to_term(Bin).
	      hello

	  Warning:
	      When  decoding  binaries	from untrusted sources,	consider using
	      binary_to_term/2 to prevent Denial of Service attacks.

	      See also term_to_binary/1	and binary_to_term/2.

       binary_to_term(Binary, Opts) -> term() |	{term(), Used}

	      Types:

		 Binary	= ext_binary()
		 Opt = safe | used
		 Opts =	[Opt]
		 Used =	integer() >= 1

	      As binary_to_term/1, but takes these options:

		safe:
		  Use this option when receiving binaries  from	 an  untrusted
		  source.

		  When	enabled, it prevents decoding data that	can be used to
		  attack the Erlang system. In the event of  receiving	unsafe
		  data,	decoding fails with a badarg error.

		  This	prevents  creation  of new atoms directly, creation of
		  new atoms indirectly (as they	are embedded in	certain	struc-
		  tures,  such	as  process  identifiers, refs,	and funs), and
		  creation of new external function references.	None of	 those
		  resources  are  garbage  collected, so unchecked creation of
		  them can exhaust available memory.

		> binary_to_term(<<131,100,0,5,"hello">>, [safe]).
		** exception error: bad	argument
		> hello.
		hello
		> binary_to_term(<<131,100,0,5,"hello">>, [safe]).
		hello

		used:
		  Changes the return value to {Term, Used} where Used  is  the
		  number of bytes actually read	from Binary.

		> Input	= <<131,100,0,5,"hello","world">>.
		<<131,100,0,5,104,101,108,108,111,119,111,114,108,100>>
		> {Term, Used} = binary_to_term(Input, [used]).
		{hello,	9}
		> split_binary(Input, Used).
		{<<131,100,0,5,104,101,108,108,111>>, <<"world">>}

	      Failure: badarg if safe is specified and unsafe data is decoded.

	      See  also	term_to_binary/1, binary_to_term/1, and	list_to_exist-
	      ing_atom/1.

       bit_size(Bitstring) -> integer()	>= 0

	      Types:

		 Bitstring = bitstring()

	      Returns an integer that is the size in bits  of  Bitstring,  for
	      example:

	      >	bit_size(<<433:16,3:3>>).
	      19
	      >	bit_size(<<1,2,3>>).
	      24

	      Allowed in guard tests.

       bitstring_to_list(Bitstring) -> [byte() | bitstring()]

	      Types:

		 Bitstring = bitstring()

	      Returns  a  list	of integers corresponding to the bytes of Bit-
	      string. If the number of bits in the binary is not divisible  by
	      8,  the  last  element of	the list is a bitstring	containing the
	      remaining	1-7 bits.

       erlang:bump_reductions(Reductions) -> true

	      Types:

		 Reductions = integer()	>= 1

	      This implementation-dependent function increments	the  reduction
	      counter  for  the	calling	process. In the	Beam emulator, the re-
	      duction counter is normally incremented by one for each function
	      and  BIF	call.  A  context  switch  is  forced when the counter
	      reaches the maximum number of reductions for a process (2000 re-
	      ductions in Erlang/OTP R12B).

	  Warning:
	      This  BIF	can be removed in a future version of the Beam machine
	      without prior warning. It	is unlikely to be implemented in other
	      Erlang implementations.

       byte_size(Bitstring) -> integer() >= 0

	      Types:

		 Bitstring = bitstring()

	      Returns an integer that is the number of bytes needed to contain
	      Bitstring. That is, if the number	of bits	in  Bitstring  is  not
	      divisible	by 8, the resulting number of bytes is rounded up. Ex-
	      amples:

	      >	byte_size(<<433:16,3:3>>).
	      3
	      >	byte_size(<<1,2,3>>).
	      3

	      Allowed in guard tests.

       erlang:cancel_timer(TimerRef) ->	Result

	      Types:

		 TimerRef = reference()
		 Time =	integer() >= 0
		 Result	= Time | false

	      Cancels a	timer. The same	as calling  erlang:cancel_timer(Timer-
	      Ref, []).

       erlang:cancel_timer(TimerRef, Options) -> Result	| ok

	      Types:

		 TimerRef = reference()
		 Async = Info =	boolean()
		 Option	= {async, Async} | {info, Info}
		 Options = [Option]
		 Time =	integer() >= 0
		 Result	= Time | false

	      Cancels  a  timer	that has been created by erlang:start_timer or
	      erlang:send_after. TimerRef identifies the timer,	 and  was  re-
	      turned by	the BIF	that created the timer.

	      Options:

		{async,	Async}:
		  Asynchronous	request	 for  cancellation.  Async defaults to
		  false, which causes the cancellation to  be  performed  syn-
		  chronously.  When Async is set to true, the cancel operation
		  is performed asynchronously. That is,	 cancel_timer()	 sends
		  an  asynchronous  request for	cancellation to	the timer ser-
		  vice that manages the	timer, and then	returns	ok.

		{info, Info}:
		  Requests information about the Result	of  the	 cancellation.
		  Info defaults	to true, which means the Result	is given. When
		  Info is set to false,	no information about the result	of the
		  cancellation is given.

		  * When  Async	 is  false: if Info is true, the Result	is re-
		    turned by erlang:cancel_timer(). otherwise ok is returned.

		  * When Async is true:	if Info	is true, a message on the form
		    {cancel_timer,  TimerRef, Result} is sent to the caller of
		    erlang:cancel_timer() when the cancellation	operation  has
		    been performed, otherwise no message is sent.

	      More Options may be added	in the future.

	      If  Result is an integer,	it represents the time in milliseconds
	      left until the canceled timer would have expired.

	      If Result	is false, a timer corresponding	to TimerRef could  not
	      be  found. This can be either because the	timer had expired, al-
	      ready had	been canceled, or because TimerRef never  corresponded
	      to  a timer. Even	if the timer had expired, it does not tell you
	      if the time-out message has arrived at its destination yet.

	  Note:
	      The timer	service	that manages the timer can be co-located  with
	      another scheduler	than the scheduler that	the calling process is
	      executing	on. If so, communication with the timer	service	 takes
	      much  longer  time than if it is located locally.	If the calling
	      process is in critical path, and can do other things while wait-
	      ing  for	the  result of this operation, or is not interested in
	      the result of the	operation, you	want  to  use  option  {async,
	      true}.  If  using	 option	 {async,  false},  the calling process
	      blocks until the operation has been performed.

	      See  also	 erlang:send_after/4,  erlang:start_timer/4,  and  er-
	      lang:read_timer/2.

       ceil(Number) -> integer()

	      Types:

		 Number	= number()

	      Returns the smallest integer not less than Number. For example:

	      >	ceil(5.5).
	      6

	      Allowed in guard tests.

       check_old_code(Module) -> boolean()

	      Types:

		 Module	= module()

	      Returns true if Module has old code, otherwise false.

	      See also code(3).

       check_process_code(Pid, Module) -> CheckResult

	      Types:

		 Pid = pid()
		 Module	= module()
		 CheckResult = boolean()

	      The same as check_process_code(Pid, Module, []).

       check_process_code(Pid, Module, OptionList) -> CheckResult | async

	      Types:

		 Pid = pid()
		 Module	= module()
		 RequestId = term()
		 Option	= {async, RequestId} | {allow_gc, boolean()}
		 OptionList = [Option]
		 CheckResult = boolean() | aborted

	      Checks  if the node local	process	identified by Pid executes old
	      code for Module.

	      Options:

		{allow_gc, boolean()}:
		  Determines if	garbage	collection is allowed when  performing
		  the operation. If {allow_gc, false} is passed, and a garbage
		  collection is	needed to determine the	result of  the	opera-
		  tion,	 the operation is aborted (see information on CheckRe-
		  sult below). The default is  to  allow  garbage  collection,
		  that is, {allow_gc, true}.

		{async,	RequestId}:
		  The  function	 check_process_code/3  returns the value async
		  immediately after the	request	has been sent.	When  the  re-
		  quest	has been processed, the	process	that called this func-
		  tion is passed a message on  the  form  {check_process_code,
		  RequestId, CheckResult}.

	      If  Pid  equals self(), and no async option has been passed, the
	      operation	is performed at	once. Otherwise	a request for the  op-
	      eration is sent to the process identified	by Pid,	and is handled
	      when appropriate.	If no async option has been passed, the	caller
	      blocks until CheckResult is available and	can be returned.

	      CheckResult informs about	the result of the request as follows:

		true:
		  The  process identified by Pid executes old code for Module.
		  That is, the current call of the process executes  old  code
		  for  this  module, or	the process has	references to old code
		  for this module, or the process contains  funs  that	refer-
		  ences	old code for this module.

		false:
		  The  process identified by Pid does not execute old code for
		  Module.

		aborted:
		  The operation	was aborted,  as  the  process	needed	to  be
		  garbage collected to determine the operation result, and the
		  operation was	requested by passing option {allow_gc, false}.

	  Note:
	      Up until ERTS version 8.*,  the  check  process  code  operation
	      checks for all types of references to the	old code. That is, di-
	      rect references (e.g. return addresses on	 the  process  stack),
	      indirect references (funs	in process context), and references to
	      literals in the code.

	      As of ERTS version 9.0, the check	process	 code  operation  only
	      checks  for  direct  references to the code. Indirect references
	      via funs will be ignored.	If such	funs exist and are used	 after
	      a	 purge of the old code,	an exception will be raised upon usage
	      (same as the case	when the fun is	received by the	process	 after
	      the  purge).  Literals will be taken care	of (copied) at a later
	      stage. This behavior can as of ERTS version 8.1 be enabled  when
	      building	OTP, and will automatically be enabled if dirty	sched-
	      uler support is enabled.

	      See also code(3).

	      Failures:

		badarg:
		  If Pid is not	a node local process identifier.

		badarg:
		  If Module is not an atom.

		badarg:
		  If OptionList	is an invalid list of options.

       erlang:convert_time_unit(Time, FromUnit,	ToUnit)	-> ConvertedTime

	      Types:

		 Time =	ConvertedTime =	integer()
		 FromUnit = ToUnit = time_unit()

	      Converts the Time	value of time unit FromUnit to the correspond-
	      ing  ConvertedTime  value	 of  time  unit	 ToUnit. The result is
	      rounded using the	floor function.

	  Warning:
	      You can lose accuracy and	precision when converting between time
	      units.  To  minimize  such loss, collect all data	at native time
	      unit and do the conversion on the	end result.

       erlang:crc32(Data) -> integer() >= 0

	      Types:

		 Data =	iodata()

	      Computes and returns the crc32 (IEEE 802.3 style)	 checksum  for
	      Data.

       erlang:crc32(OldCrc, Data) -> integer() >= 0

	      Types:

		 OldCrc	= integer() >= 0
		 Data =	iodata()

	      Continues	computing the crc32 checksum by	combining the previous
	      checksum,	OldCrc,	with the checksum of Data.

	      The following code:

	      X	= erlang:crc32(Data1),
	      Y	= erlang:crc32(X,Data2).

	      assigns the same value to	Y as this:

	      Y	= erlang:crc32([Data1,Data2]).

       erlang:crc32_combine(FirstCrc, SecondCrc, SecondSize) ->
			       integer() >= 0

	      Types:

		 FirstCrc = SecondCrc =	SecondSize = integer() >= 0

	      Combines two previously computed crc32 checksums.	This  computa-
	      tion  requires the size of the data object for the second	check-
	      sum to be	known.

	      The following code:

	      Y	= erlang:crc32(Data1),
	      Z	= erlang:crc32(Y,Data2).

	      assigns the same value to	Z as this:

	      X	= erlang:crc32(Data1),
	      Y	= erlang:crc32(Data2),
	      Z	= erlang:crc32_combine(X,Y,iolist_size(Data2)).

       date() -> Date

	      Types:

		 Date =	calendar:date()

	      Returns the current date as {Year, Month,	Day}.

	      The time zone and	Daylight Saving	Time correction	depend on  the
	      underlying OS. Example:

	      >	date().
	      {1995,2,19}

       erlang:decode_packet(Type, Bin, Options)	->
			       {ok, Packet, Rest} |
			       {more, Length} |
			       {error, Reason}

	      Types:

		 Type =
		     raw |
		     0 |
		     1 |
		     2 |
		     4 |
		     asn1 |
		     cdr |
		     sunrm |
		     fcgi |
		     tpkt |
		     line |
		     http |
		     http_bin |
		     httph |
		     httph_bin
		 Bin = binary()
		 Options = [Opt]
		 Opt =
		     {packet_size, integer() >=	0} |
		     {line_length, integer() >=	0}
		 Packet	= binary() | HttpPacket
		 Rest =	binary()
		 Length	= integer() >= 0 | undefined
		 Reason	= term()
		 HttpPacket =
		     HttpRequest  |  HttpResponse  |  HttpHeader  | http_eoh |
		 HttpError
		 HttpRequest = {http_request,  HttpMethod,  HttpUri,  HttpVer-
		 sion}
		 HttpResponse =
		     {http_response, HttpVersion, integer(), HttpString}
		 HttpHeader =
		     {http_header,
		      integer(),
		      HttpField,
		      Reserved :: term(),
		      Value :: HttpString}
		 HttpError = {http_error, HttpString}
		 HttpMethod =
		     'OPTIONS' |
		     'GET' |
		     'HEAD' |
		     'POST' |
		     'PUT' |
		     'DELETE' |
		     'TRACE' |
		     HttpString
		 HttpUri =
		     '*' |
		     {absoluteURI,
		      http | https,
		      Host :: HttpString,
		      Port :: inet:port_number() | undefined,
		      Path :: HttpString} |
		     {scheme, Scheme ::	HttpString, HttpString}	|
		     {abs_path,	HttpString} |
		     HttpString
		 HttpVersion =
		     {Major :: integer() >= 0, Minor ::	integer() >= 0}
		 HttpField =
		     'Cache-Control' |
		     'Connection' |
		     'Date' |
		     'Pragma' |
		     'Transfer-Encoding' |
		     'Upgrade' |
		     'Via' |
		     'Accept' |
		     'Accept-Charset' |
		     'Accept-Encoding' |
		     'Accept-Language' |
		     'Authorization' |
		     'From' |
		     'Host' |
		     'If-Modified-Since' |
		     'If-Match'	|
		     'If-None-Match' |
		     'If-Range'	|
		     'If-Unmodified-Since' |
		     'Max-Forwards' |
		     'Proxy-Authorization' |
		     'Range' |
		     'Referer' |
		     'User-Agent' |
		     'Age' |
		     'Location'	|
		     'Proxy-Authenticate' |
		     'Public' |
		     'Retry-After' |
		     'Server' |
		     'Vary' |
		     'Warning' |
		     'Www-Authenticate'	|
		     'Allow' |
		     'Content-Base' |
		     'Content-Encoding'	|
		     'Content-Language'	|
		     'Content-Length' |
		     'Content-Location'	|
		     'Content-Md5' |
		     'Content-Range' |
		     'Content-Type' |
		     'Etag' |
		     'Expires' |
		     'Last-Modified' |
		     'Accept-Ranges' |
		     'Set-Cookie' |
		     'Set-Cookie2' |
		     'X-Forwarded-For' |
		     'Cookie' |
		     'Keep-Alive' |
		     'Proxy-Connection'	|
		     HttpString
		 HttpString = string() | binary()

	      Decodes  the  binary Bin according to the	packet protocol	speci-
	      fied by Type. Similar to the packet  handling  done  by  sockets
	      with option {packet,Type}.

	      If an entire packet is contained in Bin, it is returned together
	      with the remainder of the	binary as {ok,Packet,Rest}.

	      If Bin does not contain the entire packet, {more,Length} is  re-
	      turned.  Length is either	the expected total size	of the packet,
	      or undefined  if	the  expected  packet  size  is	 unknown.  de-
	      code_packet can then be called again with	more data added.

	      If  the  packet  does  not  conform to the protocol format, {er-
	      ror,Reason} is returned.

	      Types:

		raw | 0:
		  No packet handling is	done. The entire  binary  is  returned
		  unless it is empty.

		1 | 2 |	4:
		  Packets  consist  of a header	specifying the number of bytes
		  in the packet, followed by that number of bytes. The	length
		  of  the  header can be one, two, or four bytes; the order of
		  the bytes is big-endian. The header is stripped off when the
		  packet is returned.

		line:
		  A  packet  is	a line-terminated by a delimiter byte, default
		  is the latin-1 newline character. The	delimiter byte is  in-
		  cluded  in the returned packet unless	the line was truncated
		  according to option line_length.

		asn1 | cdr | sunrm | fcgi | tpkt:
		  The header is	not stripped off.

		  The meanings of the packet types are as follows:

		  asn1 - ASN.1 BER:

		  sunrm	- Sun's	RPC encoding:

		  cdr -	CORBA (GIOP 1.1):

		  fcgi - Fast CGI:

		  tpkt - TPKT format [RFC1006]:

		http | httph | http_bin	| httph_bin:
		  The Hypertext	Transfer Protocol. The	packets	 are  returned
		  with the format according to HttpPacket described earlier. A
		  packet is either a request, a	response, a header, or an  end
		  of header mark. Invalid lines	are returned as	HttpError.

		  Recognized request methods and header	fields are returned as
		  atoms. Others	are returned as	strings. Strings  of  unrecog-
		  nized	 header	fields are formatted with only capital letters
		  first	and after hyphen characters,  for  example,  "Sec-Web-
		  socket-Key".

		  The protocol type http is only to be used for	the first line
		  when an HttpRequest or an HttpResponse is expected. The fol-
		  lowing  calls	 are  to  use  httph  to get HttpHeaders until
		  http_eoh is returned,	which marks the	end of the headers and
		  the beginning	of any following message body.

		  The  variants	 http_bin  and httph_bin return	strings	(Http-
		  String) as binaries instead of lists.

	      Options:

		{packet_size, integer()	_= 0}:
		  Sets the maximum allowed size	of the	packet	body.  If  the
		  packet  header  indicates  that  the length of the packet is
		  longer than the maximum allowed length, the packet  is  con-
		  sidered invalid. Defaults to 0, which	means no size limit.

		{line_length, integer()	_= 0}:
		  For packet type line,	lines longer than the indicated	length
		  are truncated.

		  Option line_length also applies to http* packet types	as  an
		  alias	 for  option  packet_size if packet_size itself	is not
		  set. This use	is only	intended for backward compatibility.

		{line_delimiter, 0 =_ byte() =_	255}:
		  For packet type line,	sets the delimiting byte.  Default  is
		  the latin-1 character	$\n.

	      Examples:

	      >	erlang:decode_packet(1,<<3,"abcd">>,[]).
	      {ok,<<"abc">>,<<"d">>}
	      >	erlang:decode_packet(1,<<5,"abcd">>,[]).
	      {more,6}

       erlang:delete_element(Index, Tuple1) -> Tuple2

	      Types:

		 Index = integer() >= 1
		   1..tuple_size(Tuple1)
		 Tuple1	= Tuple2 = tuple()

	      Returns a	new tuple with element at Index	removed	from tuple Tu-
	      ple1, for	example:

	      >	erlang:delete_element(2, {one, two, three}).
	      {one,three}

       delete_module(Module) ->	true | undefined

	      Types:

		 Module	= module()

	      Makes the	current	code for Module	become old  code  and  deletes
	      all  references  for  this module	from the export	table. Returns
	      undefined	if the module does not exist, otherwise	true.

	  Warning:
	      This BIF is intended for the code	server (see  code(3))  and  is
	      not to be	used elsewhere.

	      Failure: badarg if there already is an old version of Module.

       demonitor(MonitorRef) ->	true

	      Types:

		 MonitorRef = reference()

	      If  MonitorRef  is a reference that the calling process obtained
	      by calling monitor/2, this monitoring is turned off. If the mon-
	      itoring is already turned	off, nothing happens.

	      Once  demonitor(MonitorRef)  has returned, it is guaranteed that
	      no {'DOWN', MonitorRef, _, _, _} message,	because	of  the	 moni-
	      tor,  will  be placed in the caller message queue	in the future.
	      However, a {'DOWN', MonitorRef, _, _, _} message can  have  been
	      placed in	the caller message queue before	the call. It is	there-
	      fore usually advisable to	remove such a 'DOWN' message from  the
	      message queue after monitoring has been stopped. demonitor(Moni-
	      torRef, [flush]) can be used instead of demonitor(MonitorRef) if
	      this cleanup is wanted.

	  Note:
	      Before Erlang/OTP	R11B (ERTS 5.5)	demonitor/1 behaved completely
	      asynchronously, that is, the monitor was active until  the  "de-
	      monitor signal" reached the monitored entity. This had one unde-
	      sirable effect. You could	never know when	 you  were  guaranteed
	      not to receive a DOWN message because of the monitor.

	      The  current  behavior can be viewed as two combined operations:
	      asynchronously send a "demonitor signal" to the monitored	entity
	      and ignore any future results of the monitor.

	      Failure:	It  is	an  error if MonitorRef	refers to a monitoring
	      started by another process. Not all  such	 cases	are  cheap  to
	      check. If	checking is cheap, the call fails with badarg, for ex-
	      ample if MonitorRef is a remote reference.

       demonitor(MonitorRef, OptionList) -> boolean()

	      Types:

		 MonitorRef = reference()
		 OptionList = [Option]
		 Option	= flush	| info

	      The returned value is true unless	info is	part of	OptionList.

	      demonitor(MonitorRef, [])	is  equivalent	to  demonitor(Monitor-
	      Ref).

	      Options:

		flush:
		  Removes  (one) {_, MonitorRef, _, _, _} message, if there is
		  one, from the	caller message queue after monitoring has been
		  stopped.

		  Calling  demonitor(MonitorRef, [flush]) is equivalent	to the
		  following, but more efficient:

		demonitor(MonitorRef),
		receive
		    {_,	MonitorRef, _, _, _} ->
			true
		after 0	->
			true
		end

		info:
		  The returned value is	one of the following:

		  true:
		    The	monitor	was found and removed. In this case, no	'DOWN'
		    message  corresponding  to this monitor has	been delivered
		    and	will not be delivered.

		  false:
		    The	monitor	was not	found and could	not be	removed.  This
		    probably  because someone already has placed a 'DOWN' mes-
		    sage corresponding to this monitor in the  caller  message
		    queue.

		  If  option  info is combined with option flush, false	is re-
		  turned if a flush was	needed,	otherwise true.

	  Note:
	      More options can be added	in a future release.

	      Failures:

		badarg:
		  If OptionList	is not a list.

		badarg:
		  If Option is an invalid option.

		badarg:
		  The same failure as for demonitor/1.

       disconnect_node(Node) ->	boolean() | ignored

	      Types:

		 Node =	node()

	      Forces the disconnection of a node. This	appears	 to  the  node
	      Node  as	if the local node has crashed. This BIF	is mainly used
	      in the Erlang network authentication protocols.

	      Returns true if disconnection succeeds, otherwise	false. If  the
	      local node is not	alive, ignored is returned.

       erlang:display(Term) -> true

	      Types:

		 Term =	term()

	      Prints a text representation of Term on the standard output.

	  Warning:
	      This BIF is intended for debugging only.

       erlang:dist_ctrl_get_data(DHandle) -> Data | none

	      Types:

		 DHandle = dist_handle()
		 Data =	iodata()

	      Get  distribution	channel	data from the local node that is to be
	      passed to	the remote node. The distribution channel  is  identi-
	      fied  by	DHandle. If no data is available, the atom none	is re-
	      turned. One can request to be informed by	a  message  when  more
	      data is available	by calling erlang:dist_ctrl_get_data_notifica-
	      tion(DHandle).

	  Note:
	      Only the process registered as distribution controller  for  the
	      distribution  channel  identified	 by DHandle is allowed to call
	      this function.

	      This function is used when implementing an alternative distribu-
	      tion  carrier using processes as distribution controllers. DHan-
	      dle is retrived via the callback f_handshake_complete. More  in-
	      formation	can be found in	the documentation of ERTS User's Guide
	      ^a	How to implement an Alternative	Carrier	for the	Erlang Distri-
	      bution ^a Distribution Module.

       erlang:dist_ctrl_get_data_notification(DHandle) -> ok

	      Types:

		 DHandle = dist_handle()

	      Request  notification when more data is available	to fetch using
	      erlang:dist_ctrl_get_data(DHandle) for the distribution  channel
	      identified  by  DHandle.	When  more data	is present, the	caller
	      will be sent the message dist_data. Once	a  dist_data  messages
	      has been sent, no	more dist_data messages	will be	sent until the
	      dist_ctrl_get_data_notification/1	 function  has	 been	called
	      again.

	  Note:
	      Only  the	 process registered as distribution controller for the
	      distribution channel identified by DHandle is  allowed  to  call
	      this function.

	      This function is used when implementing an alternative distribu-
	      tion carrier using processes as distribution controllers.	 DHan-
	      dle  is retrived via the callback	f_handshake_complete. More in-
	      formation	can be found in	the documentation of ERTS User's Guide
	      ^a	How to implement an Alternative	Carrier	for the	Erlang Distri-
	      bution ^a Distribution Module.

       erlang:dist_ctrl_input_handler(DHandle, InputHandler) ->	ok

	      Types:

		 DHandle = dist_handle()
		 InputHandler =	pid()

	      Register an alternate input handler process for the distribution
	      channel  identified  by  DHandle.	 Once  this  function has been
	      called, InputHandler is the only process	allowed	 to  call  er-
	      lang:dist_ctrl_put_data(DHandle,	Data) with the DHandle identi-
	      fing this	distribution channel.

	  Note:
	      Only the process registered as distribution controller  for  the
	      distribution  channel  identified	 by DHandle is allowed to call
	      this function.

	      This function is used when implementing an alternative distribu-
	      tion  carrier using processes as distribution controllers. DHan-
	      dle is retrived via the callback f_handshake_complete. More  in-
	      formation	can be found in	the documentation of ERTS User's Guide
	      ^a	How to implement an Alternative	Carrier	for the	Erlang Distri-
	      bution ^a Distribution Module.

       erlang:dist_ctrl_put_data(DHandle, Data)	-> ok

	      Types:

		 DHandle = dist_handle()
		 Data =	iodata()

	      Deliver  distribution channel data from a	remote node to the lo-
	      cal node.

	  Note:
	      Only the process registered as distribution controller  for  the
	      distribution  channel  identified	 by DHandle is allowed to call
	      this function unless an alternate	input handler process has been
	      registered   using  erlang:dist_ctrl_input_handler(DHandle,  In-
	      putHandler). If an alternate input handler has been  registered,
	      only  the	 registered  input  handler process is allowed to call
	      this function.

	      This function is used when implementing an alternative distribu-
	      tion  carrier using processes as distribution controllers. DHan-
	      dle is retrived via the callback f_handshake_complete. More  in-
	      formation	can be found in	the documentation of ERTS User's Guide
	      ^a	How to implement an Alternative	Carrier	for the	Erlang Distri-
	      bution ^a Distribution Module.

       element(N, Tuple) -> term()

	      Types:

		 N = integer() >= 1
		   1..tuple_size(Tuple)
		 Tuple = tuple()

	      Returns  the  Nth	element	(numbering from	1) of Tuple, for exam-
	      ple:

	      >	element(2, {a, b, c}).
	      b

	      Allowed in guard tests.

       erase() -> [{Key, Val}]

	      Types:

		 Key = Val = term()

	      Returns the process dictionary and deletes it, for example:

	      >	put(key1, {1, 2, 3}),
	      put(key2,	[a, b, c]),
	      erase().
	      [{key1,{1,2,3}},{key2,[a,b,c]}]

       erase(Key) -> Val | undefined

	      Types:

		 Key = Val = term()

	      Returns the value	Val associated with Key	and  deletes  it  from
	      the process dictionary. Returns undefined	if no value is associ-
	      ated with	Key. Example:

	      >	put(key1, {merry, lambs, are, playing}),
	      X	= erase(key1),
	      {X, erase(key1)}.
	      {{merry,lambs,are,playing},undefined}

       error(Reason) ->	no_return()

	      Types:

		 Reason	= term()

	      Stops the	execution of the calling process with the reason  Rea-
	      son,  where  Reason  is  any  term.  The exit reason is {Reason,
	      Where}, where Where is a list of	the  functions	most  recently
	      called (the current function first). As evaluating this function
	      causes the process to terminate, it has no return	 value.	 Exam-
	      ple:

	      >	catch error(foobar).
	      {'EXIT',{foobar,[{shell,apply_fun,3,
				      [{file,"shell.erl"},{line,906}]},
			       {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,677}]},
			       {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,430}]},
			       {shell,exprs,7,[{file,"shell.erl"},{line,687}]},
			       {shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]},
			       {shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}]}}

       error(Reason, Args) -> no_return()

	      Types:

		 Reason	= term()
		 Args =	[term()]

	      Stops  the execution of the calling process with the reason Rea-
	      son, where Reason	is any	term.  The  exit  reason  is  {Reason,
	      Where},  where  Where  is	 a list	of the functions most recently
	      called (the current function first). Args	is expected to be  the
	      list  of	arguments for the current function; in Beam it is used
	      to provide the arguments for the current function	 in  the  term
	      Where.  As evaluating this function causes the process to	termi-
	      nate, it has no return value.

       exit(Reason) -> no_return()

	      Types:

		 Reason	= term()

	      Stops the	execution of the calling process with exit reason Rea-
	      son,  where  Reason  is  any  term.  As evaluating this function
	      causes the process to terminate, it has no return	 value.	 Exam-
	      ple:

	      >	exit(foobar).
	      ** exception exit: foobar
	      >	catch exit(foobar).
	      {'EXIT',foobar}

       exit(Pid, Reason) -> true

	      Types:

		 Pid = pid() | port()
		 Reason	= term()

	      Sends  an	 exit signal with exit reason Reason to	the process or
	      port identified by Pid.

	      The following behavior applies if	Reason	is  any	 term,	except
	      normal or	kill:

		* If  Pid  is  not  trapping exits, Pid	itself exits with exit
		  reason Reason.

		* If Pid is trapping exits, the	 exit  signal  is  transformed
		  into	a  message {'EXIT', From, Reason} and delivered	to the
		  message queue	of Pid.

		* From is the process identifier of the	process	that sent  the
		  exit signal. See also	process_flag/2.

	      If  Reason is the	atom normal, Pid does not exit.	If it is trap-
	      ping exits, the  exit  signal  is	 transformed  into  a  message
	      {'EXIT', From, normal} and delivered to its message queue.

	      If  Reason  is  the  atom	 kill,	that is, if exit(Pid, kill) is
	      called, an untrappable exit signal is sent to Pid, which	uncon-
	      ditionally exits with exit reason	killed.

       erlang:external_size(Term) -> integer() >= 0

	      Types:

		 Term =	term()

	      Calculates,  without  doing  the encoding, the maximum byte size
	      for a term encoded in the	Erlang external	term format. The  fol-
	      lowing condition applies always:

	      >	Size1 =	byte_size(term_to_binary(Term)),
	      >	Size2 =	erlang:external_size(Term),
	      >	true = Size1 =<	Size2.
	      true

	      This is equivalent to a call to:

	      erlang:external_size(Term, [])

       erlang:external_size(Term, Options) -> integer()	>= 0

	      Types:

		 Term =	term()
		 Options = [{minor_version, Version :: integer() >= 0}]

	      Calculates,  without  doing  the encoding, the maximum byte size
	      for a term encoded in the	Erlang external	term format. The  fol-
	      lowing condition applies always:

	      >	Size1 =	byte_size(term_to_binary(Term, Options)),
	      >	Size2 =	erlang:external_size(Term, Options),
	      >	true = Size1 =<	Size2.
	      true

	      Option  {minor_version,  Version}	 specifies  how	floats are en-
	      coded. For a detailed description, see term_to_binary/2.

       float(Number) ->	float()

	      Types:

		 Number	= number()

	      Returns a	float by converting Number to a	float, for example:

	      >	float(55).
	      55.0

	      Allowed in guard tests.

	  Note:
	      If used on the top level in a guard, it tests whether the	 argu-
	      ment is a	floating point number; for clarity, use	is_float/1 in-
	      stead.

	      When float/1 is used in  an  expression  in  a  guard,  such  as
	      'float(A)	== 4.0', it converts a number as described earlier.

       float_to_binary(Float) -> binary()

	      Types:

		 Float = float()

	      The same as float_to_binary(Float,[{scientific,20}]).

       float_to_binary(Float, Options) -> binary()

	      Types:

		 Float = float()
		 Options = [Option]
		 Option	=
		     {decimals,	Decimals :: 0..253} |
		     {scientific, Decimals :: 0..249} |
		     compact

	      Returns  a  binary  corresponding	 to the	text representation of
	      Float using fixed	decimal	point formatting. Options  behaves  in
	      the same way as float_to_list/2. Examples:

	      >	float_to_binary(7.12, [{decimals, 4}]).
	      <<"7.1200">>
	      >	float_to_binary(7.12, [{decimals, 4}, compact]).
	      <<"7.12">>

       float_to_list(Float) -> string()

	      Types:

		 Float = float()

	      The same as float_to_list(Float,[{scientific,20}]).

       float_to_list(Float, Options) ->	string()

	      Types:

		 Float = float()
		 Options = [Option]
		 Option	=
		     {decimals,	Decimals :: 0..253} |
		     {scientific, Decimals :: 0..249} |
		     compact

	      Returns  a  string  corresponding	 to the	text representation of
	      Float using fixed	decimal	point formatting.

	      Available	options:

		* If option decimals is	specified, the returned	value contains
		  at most Decimals number of digits past the decimal point. If
		  the number does not fit in the internal static buffer	of 256
		  bytes, the function throws badarg.

		* If  option  compact  is specified, the trailing zeros	at the
		  end of the list are truncated. This option is	only  meaning-
		  ful together with option decimals.

		* If  option  scientific  is specified,	the float is formatted
		  using	scientific notation with Decimals digits of precision.

		* If Options is	[], the	function behaves as float_to_list/1.

	      Examples:

	      >	float_to_list(7.12, [{decimals,	4}]).
	      "7.1200"
	      >	float_to_list(7.12, [{decimals,	4}, compact]).
	      "7.12"

       floor(Number) ->	integer()

	      Types:

		 Number	= number()

	      Returns the largest integer not greater than Number.  For	 exam-
	      ple:

	      >	floor(-10.5).
	      -11

	      Allowed in guard tests.

       erlang:fun_info(Fun) -> [{Item, Info}]

	      Types:

		 Fun = function()
		 Item =
		     arity |
		     env |
		     index |
		     name |
		     module |
		     new_index |
		     new_uniq |
		     pid |
		     type |
		     uniq
		 Info =	term()

	      Returns a	list with information about the	fun Fun. Each list el-
	      ement is a tuple.	The order of the tuples	is undefined, and more
	      tuples can be added in a future release.

	  Warning:
	      This  BIF	is mainly intended for debugging, but it can sometimes
	      be useful	in library functions that need to verify, for example,
	      the arity	of a fun.

	      Two types	of funs	have slightly different	semantics:

		* A  fun created by fun	M:F/A is called	an external fun. Call-
		  ing it will always call the function F with arity A  in  the
		  latest code for module M. Notice that	module M does not even
		  need to be loaded when the fun fun M:F/A is created.

		* All other funs are called local. When	a local	fun is called,
		  the  same version of the code	that created the fun is	called
		  (even	if a newer version of the module has been loaded).

	      The following elements are always	present	in the list  for  both
	      local and	external funs:

		{type, Type}:
		  Type is local	or external.

		{module, Module}:
		  Module (an atom) is the module name.

		  If Fun is a local fun, Module	is the module in which the fun
		  is defined.

		  If Fun is an external	fun, Module is the module that the fun
		  refers to.

		{name, Name}:
		  Name (an atom) is a function name.

		  If  Fun  is a	local fun, Name	is the name of the local func-
		  tion that implements the fun.	(This name  was	 generated  by
		  the  compiler,  and is only of informational use. As it is a
		  local	function, it cannot be called directly.) If no code is
		  currently  loaded  for the fun, [] is	returned instead of an
		  atom.

		  If Fun is an external	fun, Name is the name of the  exported
		  function that	the fun	refers to.

		{arity,	Arity}:
		  Arity	 is  the  number  of  arguments	 that the fun is to be
		  called with.

		{env, Env}:
		  Env (a list) is the environment or free  variables  for  the
		  fun. For external funs, the returned list is always empty.

	      The  following  elements	are only present in the	list if	Fun is
	      local:

		{pid, Pid}:
		  Pid is the process identifier	of the process that originally
		  created the fun.

		{index,	Index}:
		  Index	(an integer) is	an index into the module fun table.

		{new_index, Index}:
		  Index	(an integer) is	an index into the module fun table.

		{new_uniq, Uniq}:
		  Uniq (a binary) is a unique value for	this fun. It is	calcu-
		  lated	from the compiled code for the entire module.

		{uniq, Uniq}:
		  Uniq (an integer) is a unique	value for this	fun.  As  from
		  Erlang/OTP R15, this integer is calculated from the compiled
		  code for the entire module. Before Erlang/OTP	R15, this  in-
		  teger	was based on only the body of the fun.

       erlang:fun_info(Fun, Item) -> {Item, Info}

	      Types:

		 Fun = function()
		 Item =	fun_info_item()
		 Info =	term()
		 fun_info_item() =
		     arity |
		     env |
		     index |
		     name |
		     module |
		     new_index |
		     new_uniq |
		     pid |
		     type |
		     uniq

	      Returns  information about Fun as	specified by Item, in the form
	      {Item,Info}.

	      For any fun, Item	can be any of the atoms	module,	 name,	arity,
	      env, or type.

	      For  a  local  fun,  Item	 can  also  be any of the atoms	index,
	      new_index, new_uniq, uniq, and pid. For  an  external  fun,  the
	      value of any of these items is always the	atom undefined.

	      See erlang:fun_info/1.

       erlang:fun_to_list(Fun) -> string()

	      Types:

		 Fun = function()

	      Returns  a  string  corresponding	 to the	text representation of
	      Fun.

       erlang:function_exported(Module,	Function, Arity) -> boolean()

	      Types:

		 Module	= module()
		 Function = atom()
		 Arity = arity()

	      Returns true if the module Module	is loaded and contains an  ex-
	      ported function Function/Arity, or if there is a BIF (a built-in
	      function implemented in C) with the  specified  name,  otherwise
	      returns false.

	  Note:
	      This  function  used  to return false for	BIFs before Erlang/OTP
	      18.0.

       garbage_collect() -> true

	      Forces an	immediate garbage collection of	the executing process.
	      The  function  is	 not to	be used	unless it has been noticed (or
	      there are	good reasons to	suspect) that the spontaneous  garbage
	      collection will occur too	late or	not at all.

	  Warning:
	      Improper use can seriously degrade system	performance.

       garbage_collect(Pid) -> GCResult

	      Types:

		 Pid = pid()
		 GCResult = boolean()

	      The same as garbage_collect(Pid, []).

       garbage_collect(Pid, OptionList)	-> GCResult | async

	      Types:

		 Pid = pid()
		 RequestId = term()
		 Option	= {async, RequestId} | {type, major | minor}
		 OptionList = [Option]
		 GCResult = boolean()

	      Garbage collects the node	local process identified by Pid.

	      Option:

		{async,	RequestId}:
		  The function garbage_collect/2 returns the value async imme-
		  diately after	the request has	been sent.  When  the  request
		  has been processed, the process that called this function is
		  passed a message on the  form	 {garbage_collect,  RequestId,
		  GCResult}.

		{type, 'major' | 'minor'}:
		  Triggers garbage collection of requested type. Default value
		  is 'major', which would trigger a fullsweep GC.  The	option
		  'minor' is considered	a hint and may lead to either minor or
		  major	GC run.

	      If Pid equals self(), and	no async option	has been  passed,  the
	      garbage  collection  is  performed at once, that is, the same as
	      calling garbage_collect/0. Otherwise a request for garbage  col-
	      lection  is  sent	 to the	process	identified by Pid, and will be
	      handled when appropriate.	If no async option  has	 been  passed,
	      the  caller  blocks  until  GCResult is available	and can	be re-
	      turned.

	      GCResult informs about the result	of the garbage collection  re-
	      quest as follows:

		true:
		   The process identified by Pid has been garbage collected.

		false:
		   No garbage collection was performed,	as the process identi-
		  fied by Pid terminated before	the request  could  be	satis-
		  fied.

	      Notice that the same caveats apply as for	garbage_collect/0.

	      Failures:

		badarg:
		   If Pid is not a node	local process identifier.

		badarg:
		   If OptionList is an invalid list of options.

       get() ->	[{Key, Val}]

	      Types:

		 Key = Val = term()

	      Returns  the  process dictionary as a list of {Key, Val} tuples,
	      for example:

	      >	put(key1, merry),
	      put(key2,	lambs),
	      put(key3,	{are, playing}),
	      get().
	      [{key1,merry},{key2,lambs},{key3,{are,playing}}]

       get(Key)	-> Val | undefined

	      Types:

		 Key = Val = term()

	      Returns the value	Val associated with Key	in the process dictio-
	      nary, or undefined if Key	does not exist.	Example:

	      >	put(key1, merry),
	      put(key2,	lambs),
	      put({any,	[valid,	term]},	{are, playing}),
	      get({any,	[valid,	term]}).
	      {are,playing}

       erlang:get_cookie() -> Cookie | nocookie

	      Types:

		 Cookie	= atom()

	      Returns the magic	cookie of the local node if the	node is	alive,
	      otherwise	the atom nocookie.

       get_keys() -> [Key]

	      Types:

		 Key = term()

	      Returns a	list of	all keys present in  the  process  dictionary,
	      for example:

	      >	put(dog, {animal,1}),
	      put(cow, {animal,2}),
	      put(lamb,	{animal,3}),
	      get_keys().
	      [dog,cow,lamb]

       get_keys(Val) ->	[Key]

	      Types:

		 Val = Key = term()

	      Returns a	list of	keys that are associated with the value	Val in
	      the process dictionary, for example:

	      >	put(mary, {1, 2}),
	      put(had, {1, 2}),
	      put(a, {1, 2}),
	      put(little, {1, 2}),
	      put(dog, {1, 3}),
	      put(lamb,	{1, 2}),
	      get_keys({1, 2}).
	      [mary,had,a,little,lamb]

       erlang:get_stacktrace() -> [stack_item()]

	      Types:

		 stack_item() =
		     {Module ::	module(),
		      Function :: atom(),
		      Arity :: arity() | (Args :: [term()]),
		      Location ::
			  [{file, Filename :: string()}	|
			   {line, Line :: integer() >= 1}]}

	  Warning:
	      erlang:get_stacktrace/0 is deprecated and	will stop working in a
	      future release.

	      Instead  of  using  erlang:get_stacktrace/0 to retrieve the call
	      stack back-trace,	use the	following syntax:

	      try Expr
	      catch
		Class:Reason:Stacktrace	->
		 {Class,Reason,Stacktrace}
	      end

	      erlang:get_stacktrace/0  retrieves  the  call  stack  back-trace
	      (stacktrace)  for	 an exception that has just been caught	in the
	      calling process as a  list  of  {Module,Function,Arity,Location}
	      tuples.  Field Arity in the first	tuple can be the argument list
	      of that function call instead of an arity	integer, depending  on
	      the exception.

	      If  there	 has  not been any exceptions in a process, the	stack-
	      trace is []. After a code	change for the process,	the stacktrace
	      can also be reset	to [].

	      The  stacktrace  is the same data	as operator catch returns, for
	      example:

	      {'EXIT',{badarg,Stacktrace}} = catch abs(x)

	      Location is a (possibly empty) list of two-tuples	that can indi-
	      cate  the	location in the	source code of the function. The first
	      element is an atom describing the	type  of  information  in  the
	      second element. The following items can occur:

		file:
		  The second element of	the tuple is a string (list of charac-
		  ters)	representing the filename of the source	 file  of  the
		  function.

		line:
		  The second element of	the tuple is the line number (an inte-
		  ger >	0) in the source file where the	exception occurred  or
		  the function was called.

	  Warning:
	      Developers  should rely on stacktrace entries only for debugging
	      purposes.

	      The VM performs tail call	optimization, which does not  add  new
	      entries to the stacktrace, and also limits stacktraces to	a cer-
	      tain depth. Furthermore, compiler	options, optimizations and fu-
	      ture  changes  may add or	remove stacktrace entries, causing any
	      code that	expects	the stacktrace to be in	 a  certain  order  or
	      contain specific items to	fail.

	      The  only	exception to this rule is error:undef which guarantees
	      to include the Module, Function and Arity	of the attempted func-
	      tion as the first	stacktrace entry.

	      See also error/1 and error/2.

       group_leader() -> pid()

	      Returns  the  process  identifier	 of  the  group	leader for the
	      process evaluating the function.

	      Every process is a member	of some	process	group and  all	groups
	      have  a group leader. All	I/O from the group is channeled	to the
	      group leader. When a new process is spawned, it  gets  the  same
	      group  leader  as	 the  spawning	process.  Initially, at	system
	      startup, init is both its	own group leader and the group	leader
	      of all processes.

       group_leader(GroupLeader, Pid) -> true

	      Types:

		 GroupLeader = Pid = pid()

	      Sets  the	group leader of	Pid to GroupLeader. Typically, this is
	      used when	a process started from a certain shell is to have  an-
	      other group leader than init.

	      The group	leader should be rarely	changed	in applications	with a
	      supervision tree,	because	OTP assumes the	group leader of	 their
	      processes	is their application master.

	      See  also	 group_leader/0	 and  OTP design principles related to
	      starting and stopping applications.

       halt() -> no_return()

	      The same as halt(0, []). Example:

	      >	halt().
	      os_prompt%

       halt(Status) -> no_return()

	      Types:

		 Status	= integer() >= 0 | abort | string()

	      The same as halt(Status, []). Example:

	      >	halt(17).
	      os_prompt% echo $?
	      17
	      os_prompt%

       halt(Status, Options) ->	no_return()

	      Types:

		 Status	= integer() >= 0 | abort | string()
		 Options = [Option]
		 Option	= {flush, boolean()}

	      Status must be a non-negative integer, a	string,	 or  the  atom
	      abort. Halts the Erlang runtime system. Has no return value. De-
	      pending on Status, the following occurs:

		integer():
		  The runtime system exits with	integer	value Status as	status
		  code to the calling environment (OS).

	    Note:
		On  many platforms, the	OS supports only status	codes 0-255. A
		too large status code is truncated by clearing the high	bits.

		string():
		  An Erlang crash dump is produced with	Status as slogan. Then
		  the runtime system exits with	status code 1. The string will
		  be truncated if longer than 200 characters.

	    Note:
		Before ERTS 9.1	(OTP-20.1) only	code points in the range 0-255
		was accepted in	the string. Now	any unicode string is valid.

		abort:
		  The  runtime system aborts producing a core dump, if that is
		  enabled in the OS.

	      For integer Status, the Erlang runtime system closes  all	 ports
	      and allows async threads to finish their operations before exit-
	      ing. To exit without such	flushing, use Option as	{flush,false}.

	      For statuses string() and	abort, option  flush  is  ignored  and
	      flushing is not done.

       hd(List)	-> term()

	      Types:

		 List =	[term(), ...]

	      Returns  the head	of List, that is, the first element, for exam-
	      ple:

	      >	hd([1,2,3,4,5]).
	      1

	      Allowed in guard tests.

	      Failure: badarg if List is the empty list	[].

       erlang:hibernate(Module,	Function, Args)	-> no_return()

	      Types:

		 Module	= module()
		 Function = atom()
		 Args =	[term()]

	      Puts the calling process into a wait state where its memory  al-
	      location has been	reduced	as much	as possible. This is useful if
	      the process does not expect to receive any messages soon.

	      The process is awaken when a message is sent to it, and  control
	      resumes  in Module:Function with the arguments specified by Args
	      with the call stack emptied, meaning that	the process terminates
	      when  that  function  returns. Thus erlang:hibernate/3 never re-
	      turns to its caller.

	      If the process has any message in	its message queue, the process
	      is awakened immediately in the same way as described earlier.

	      In  more	technical  terms, erlang:hibernate/3 discards the call
	      stack for	the process, and then garbage  collects	 the  process.
	      After this, all live data	is in one continuous heap. The heap is
	      then shrunken to the exact same size as the live	data  that  it
	      holds  (even if that size	is less	than the minimum heap size for
	      the process).

	      If the size of the live data in the process  is  less  than  the
	      minimum  heap size, the first garbage collection occurring after
	      the process is awakened ensures that the heap size is changed to
	      a	size not smaller than the minimum heap size.

	      Notice  that  emptying the call stack means that any surrounding
	      catch is removed and must	be re-inserted after hibernation.  One
	      effect  of  this	is that	processes started using	proc_lib (also
	      indirectly,  such	 as  gen_server	  processes),	are   to   use
	      proc_lib:hibernate/3  instead, to	ensure that the	exception han-
	      dler continues to	work when the process wakes up.

       erlang:insert_element(Index, Tuple1, Term) -> Tuple2

	      Types:

		 Index = integer() >= 1
		   1..tuple_size(Tuple1) + 1
		 Tuple1	= Tuple2 = tuple()
		 Term =	term()

	      Returns a	new tuple with element Term inserted at	position Index
	      in  tuple	 Tuple1.  All elements from position Index and upwards
	      are pushed one step higher in the	new tuple Tuple2. Example:

	      >	erlang:insert_element(2, {one, two, three}, new).
	      {one,new,two,three}

       integer_to_binary(Integer) -> binary()

	      Types:

		 Integer = integer()

	      Returns a	binary corresponding to	the text representation	of In-
	      teger, for example:

	      >	integer_to_binary(77).
	      <<"77">>

       integer_to_binary(Integer, Base)	-> binary()

	      Types:

		 Integer = integer()
		 Base =	2..36

	      Returns a	binary corresponding to	the text representation	of In-
	      teger in base Base, for example:

	      >	integer_to_binary(1023,	16).
	      <<"3FF">>

       integer_to_list(Integer)	-> string()

	      Types:

		 Integer = integer()

	      Returns a	string corresponding to	the text representation	of In-
	      teger, for example:

	      >	integer_to_list(77).
	      "77"

       integer_to_list(Integer,	Base) -> string()

	      Types:

		 Integer = integer()
		 Base =	2..36

	      Returns a	string corresponding to	the text representation	of In-
	      teger in base Base, for example:

	      >	integer_to_list(1023, 16).
	      "3FF"

       iolist_size(Item) -> integer() >= 0

	      Types:

		 Item =	iolist() | binary()

	      Returns an integer, that is the size in  bytes,  of  the	binary
	      that would be the	result of iolist_to_binary(Item), for example:

	      >	iolist_size([1,2|<<3,4>>]).
	      4

       iolist_to_binary(IoListOrBinary)	-> binary()

	      Types:

		 IoListOrBinary	= iolist() | binary()

	      Returns  a binary	that is	made from the integers and binaries in
	      IoListOrBinary, for example:

	      >	Bin1 = <<1,2,3>>.
	      <<1,2,3>>
	      >	Bin2 = <<4,5>>.
	      <<4,5>>
	      >	Bin3 = <<6>>.
	      <<6>>
	      >	iolist_to_binary([Bin1,1,[2,3,Bin2],4|Bin3]).
	      <<1,2,3,1,2,3,4,5,4,6>>

       erlang:iolist_to_iovec(IoListOrBinary) -> iovec()

	      Types:

		 IoListOrBinary	= iolist() | binary()

	      Returns an iovec that is made from the integers and binaries  in
	      IoListOrBinary.

       is_alive() -> boolean()

	      Returns  true  if	 the local node	is alive (that is, if the node
	      can be part of a distributed system), otherwise false.

       is_atom(Term) ->	boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is an atom, otherwise false.

	      Allowed in guard tests.

       is_binary(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is a	binary,	otherwise false.

	      A	binary always contains a complete number of bytes.

	      Allowed in guard tests.

       is_bitstring(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is a	bitstring (including a binary),	other-
	      wise false.

	      Allowed in guard tests.

       is_boolean(Term)	-> boolean()

	      Types:

		 Term =	term()

	      Returns  true  if	 Term is the atom true or the atom false (that
	      is, a boolean). Otherwise	returns	false.

	      Allowed in guard tests.

       erlang:is_builtin(Module, Function, Arity) -> boolean()

	      Types:

		 Module	= module()
		 Function = atom()
		 Arity = arity()

	      This BIF is useful for builders of cross-reference tools.

	      Returns true if Module:Function/Arity is a BIF implemented in C,
	      otherwise	false.

       is_float(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns  true  if	 Term  is  a  floating point number, otherwise
	      false.

	      Allowed in guard tests.

       is_function(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is a	fun, otherwise false.

	      Allowed in guard tests.

       is_function(Term, Arity)	-> boolean()

	      Types:

		 Term =	term()
		 Arity = arity()

	      Returns true if Term is a	fun that can  be  applied  with	 Arity
	      number of	arguments, otherwise false.

	      Allowed in guard tests.

       is_integer(Term)	-> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is an integer, otherwise false.

	      Allowed in guard tests.

       is_list(Term) ->	boolean()

	      Types:

		 Term =	term()

	      Returns  true if Term is a list with zero	or more	elements, oth-
	      erwise false.

	      Allowed in guard tests.

       is_map(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is a	map, otherwise false.

	      Allowed in guard tests.

       is_map_key(Key, Map) -> boolean()

	      Types:

		 Key = term()
		 Map = map()

	      Returns true if map Map contains Key and	returns	 false	if  it
	      does not contain the Key.

	      The  call	 fails	with  a	{badmap,Map} exception if Map is not a
	      map.

	      Example:

	      >	Map = #{"42" =>	value}.
	      #{"42" =>	value}
	      >	is_map_key("42",Map).
	      true
	      >	is_map_key(value,Map).
	      false

       is_number(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is an integer or a floating	point  number.
	      Otherwise	returns	false.

	      Allowed in guard tests.

       is_pid(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is a	process	identifier, otherwise false.

	      Allowed in guard tests.

       is_port(Term) ->	boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is a	port identifier, otherwise false.

	      Allowed in guard tests.

       is_process_alive(Pid) ->	boolean()

	      Types:

		 Pid = pid()

	      Pid must refer to	a process at the local node.

	      Returns true if the process exists and is	alive, that is,	is not
	      exiting and has not exited. Otherwise returns false.

       is_record(Term, RecordTag) -> boolean()

	      Types:

		 Term =	term()
		 RecordTag = atom()

	      Returns true if Term is a	tuple and its first element is Record-
	      Tag. Otherwise returns false.

	  Note:
	      Normally the compiler treats calls to is_record/2	especially. It
	      emits code to verify that	Term is	a tuple, that its  first  ele-
	      ment  is	RecordTag,  and	 that the size is correct. However, if
	      RecordTag	is not a literal atom, the BIF is_record/2  is	called
	      instead and the size of the tuple	is not verified.

	      Allowed in guard tests, if RecordTag is a	literal	atom.

       is_record(Term, RecordTag, Size)	-> boolean()

	      Types:

		 Term =	term()
		 RecordTag = atom()
		 Size =	integer() >= 0

	      RecordTag	must be	an atom.

	      Returns true if Term is a	tuple, its first element is RecordTag,
	      and its size is Size. Otherwise returns false.

	      Allowed in guard tests if	RecordTag is a literal atom  and  Size
	      is a literal integer.

	  Note:
	      This  BIF	is documented for completeness.	Usually	is_record/2 is
	      to be used.

       is_reference(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is a	reference, otherwise false.

	      Allowed in guard tests.

       is_tuple(Term) -> boolean()

	      Types:

		 Term =	term()

	      Returns true if Term is a	tuple, otherwise false.

	      Allowed in guard tests.

       length(List) -> integer() >= 0

	      Types:

		 List =	[term()]

	      Returns the length of List, for example:

	      >	length([1,2,3,4,5,6,7,8,9]).
	      9

	      Allowed in guard tests.

       link(PidOrPort) -> true

	      Types:

		 PidOrPort = pid() | port()

	      Creates a	link between the calling process and  another  process
	      (or  port)  PidOrPort, if	there is not such a link already. If a
	      process attempts to create a link	to itself,  nothing  is	 done.
	      Returns true.

	      If  PidOrPort does not exist, the	behavior of the	BIF depends on
	      if  the  calling	process	 is  trapping  exits   or   not	  (see
	      process_flag/2):

		* If  the  calling process is not trapping exits, and checking
		  PidOrPort is cheap (that is, if PidOrPort is local),	link/1
		  fails	with reason noproc.

		* Otherwise,  if the calling process is	trapping exits,	and/or
		  PidOrPort is remote, link/1 returns true, but	an exit	signal
		  with reason noproc is	sent to	the calling process.

       list_to_atom(String) -> atom()

	      Types:

		 String	= string()

	      Returns the atom whose text representation is String.

	      As from Erlang/OTP 20, String may	contain	any Unicode character.
	      Earlier versions allowed only ISO-latin-1	characters as the  im-
	      plementation  did	 not  allow  Unicode characters	above 255. For
	      more information on Unicode support in atoms, see	note on	 UTF-8
	      encoded  atoms  in  section "External Term Format" in the	User's
	      Guide.

	      Example:

	      >	list_to_atom("Erlang").

       list_to_binary(IoList) -> binary()

	      Types:

		 IoList	= iolist()

	      Returns a	binary that is made from the integers and binaries  in
	      IoList, for example:

	      >	Bin1 = <<1,2,3>>.
	      <<1,2,3>>
	      >	Bin2 = <<4,5>>.
	      <<4,5>>
	      >	Bin3 = <<6>>.
	      <<6>>
	      >	list_to_binary([Bin1,1,[2,3,Bin2],4|Bin3]).
	      <<1,2,3,1,2,3,4,5,4,6>>

       list_to_bitstring(BitstringList)	-> bitstring()

	      Types:

		 BitstringList = bitstring_list()
		 bitstring_list() =
		     maybe_improper_list(byte()	| bitstring() |	bitstring_list(),
					 bitstring() | [])

	      Returns  a  bitstring  that  is  made from the integers and bit-
	      strings in BitstringList.	(The last tail in BitstringList	is al-
	      lowed to be a bitstring.)	Example:

	      >	Bin1 = <<1,2,3>>.
	      <<1,2,3>>
	      >	Bin2 = <<4,5>>.
	      <<4,5>>
	      >	Bin3 = <<6,7:4>>.
	      <<6,7:4>>
	      >	list_to_bitstring([Bin1,1,[2,3,Bin2],4|Bin3]).
	      <<1,2,3,1,2,3,4,5,4,6,7:4>>

       list_to_existing_atom(String) ->	atom()

	      Types:

		 String	= string()

	      Returns  the  atom whose text representation is String, but only
	      if there already exists such atom.

	      Failure: badarg if there does not	already	exist  an  atom	 whose
	      text representation is String.

	  Note:
	      Note that	the compiler may optimize away atoms. For example, the
	      compiler will rewrite atom_to_list(some_atom) to "some_atom". If
	      that expression is the only mention of the atom some_atom	in the
	      containing module, the atom will not be created when the	module
	      is   loaded,   and   a   subsequent   call   to	list_to_exist-
	      ing_atom("some_atom") will fail.

       list_to_float(String) ->	float()

	      Types:

		 String	= string()

	      Returns the float	whose text representation is String, for exam-
	      ple:

	      >	list_to_float("2.2017764e+0").
	      2.2017764

	      Failure:	badarg	if  String  contains a bad representation of a
	      float.

       list_to_integer(String) -> integer()

	      Types:

		 String	= string()

	      Returns an integer whose text representation is String, for  ex-
	      ample:

	      >	list_to_integer("123").
	      123

	      Failure:	badarg	if  String contains a bad representation of an
	      integer.

       list_to_integer(String, Base) ->	integer()

	      Types:

		 String	= string()
		 Base =	2..36

	      Returns an integer whose text representation  in	base  Base  is
	      String, for example:

	      >	list_to_integer("3FF", 16).
	      1023

	      Failure:	badarg	if  String contains a bad representation of an
	      integer.

       list_to_pid(String) -> pid()

	      Types:

		 String	= string()

	      Returns a	process	identifier  whose  text	 representation	 is  a
	      String, for example:

	      >	list_to_pid("<0.4.1>").
	      <0.4.1>

	      Failure:	badarg	if  String  contains a bad representation of a
	      process identifier.

	  Warning:
	      This BIF is intended for debugging and is	not to be used in  ap-
	      plication	programs.

       list_to_port(String) -> port()

	      Types:

		 String	= string()

	      Returns a	port identifier	whose text representation is a String,
	      for example:

	      >	list_to_port("#Port<0.4>").
	      #Port<0.4>

	      Failure: badarg if String	contains a  bad	 representation	 of  a
	      port identifier.

	  Warning:
	      This  BIF	is intended for	debugging and is not to	be used	in ap-
	      plication	programs.

       list_to_ref(String) -> reference()

	      Types:

		 String	= string()

	      Returns a	reference whose	text representation is a  String,  for
	      example:

	      >	list_to_ref("#Ref<0.4192537678.4073193475.71181>").
	      #Ref<0.4192537678.4073193475.71181>

	      Failure:	badarg	if  String  contains a bad representation of a
	      reference.

	  Warning:
	      This BIF is intended for debugging and is	not to be used in  ap-
	      plication	programs.

       list_to_tuple(List) -> tuple()

	      Types:

		 List =	[term()]

	      Returns a	tuple corresponding to List, for example

	      >	list_to_tuple([share, ['Ericsson_B', 163]]).
	      {share, ['Ericsson_B', 163]}

	      List can contain any Erlang terms.

       load_module(Module, Binary) -> {module, Module} | {error, Reason}

	      Types:

		 Module	= module()
		 Binary	= binary()
		 Reason	= badfile | not_purged | on_load

	      If  Binary  contains the object code for module Module, this BIF
	      loads that object	code. If the code for  module  Module  already
	      exists,  all export references are replaced so they point	to the
	      newly loaded code. The previously	loaded code  is	 kept  in  the
	      system  as  old  code, as	there can still	be processes executing
	      that code.

	      Returns either {module, Module}, or {error, Reason}  if  loading
	      fails. Reason is one of the following:

		badfile:
		  The object code in Binary has	an incorrect format or the ob-
		  ject code contains code for another module than Module.

		not_purged:
		  Binary contains a module that	cannot be loaded  because  old
		  code for this	module already exists.

	  Warning:
	      This  BIF	 is  intended for the code server (see code(3))	and is
	      not to be	used elsewhere.

       erlang:load_nif(Path, LoadInfo) -> ok | Error

	      Types:

		 Path =	string()
		 LoadInfo = term()
		 Error = {error, {Reason, Text :: string()}}
		 Reason	=
		     load_failed |  bad_lib  |	load  |	 reload	 |  upgrade  |
		 old_code

	      Loads  and links a dynamic library containing native implemented
	      functions	(NIFs) for a module. Path is a file path to the	share-
	      able object/dynamic library file minus the OS-dependent file ex-
	      tension (.so for Unix and	.dll for Windows). Notice that on most
	      OSs the library has to have a different name on disc when	an up-
	      grade of the nif is done.	If the name is the same, but the  con-
	      tents  differ, the old library may be loaded instead. For	infor-
	      mation on	how to implement a NIF library,	see erl_nif(3).

	      LoadInfo can be any term.	It is passed on	to the library as part
	      of  the  initialization.	A good practice	is to include a	module
	      version number to	support	future code upgrade scenarios.

	      The call to load_nif/2 must be made  directly  from  the	Erlang
	      code  of	the module that	the NIF	library	belongs	to. It returns
	      either ok, or {error,{Reason,Text}} if loading fails. Reason  is
	      one of the following atoms while Text is a human readable	string
	      that can give more information about the failure:

		load_failed:
		  The OS failed	to load	the NIF	library.

		bad_lib:
		  The library did not fulfill the requirements as  a  NIF  li-
		  brary	of the calling module.

		load | upgrade:
		  The corresponding library callback was unsuccessful.

		reload:
		  A  NIF  library  is already loaded for this module instance.
		  The previously deprecated reload feature was removed in  OTP
		  20.

		old_code:
		  The  call to load_nif/2 was made from	the old	code of	a mod-
		  ule that has been upgraded; this is not allowed.

		notsup:
		  Lack of support. Such	as loading NIF library for a HiPE com-
		  piled	module.

       erlang:loaded() -> [Module]

	      Types:

		 Module	= module()

	      Returns  a  list	of  all	loaded Erlang modules (current and old
	      code), including preloaded modules.

	      See also code(3).

       erlang:localtime() -> DateTime

	      Types:

		 DateTime = calendar:datetime()

	      Returns the current local	date and time,	{{Year,	 Month,	 Day},
	      {Hour, Minute, Second}}, for example:

	      >	erlang:localtime().
	      {{1996,11,6},{14,45,17}}

	      The  time	zone and Daylight Saving Time correction depend	on the
	      underlying OS.

       erlang:localtime_to_universaltime(Localtime) -> Universaltime

	      Types:

		 Localtime = Universaltime = calendar:datetime()

	      Converts local date  and	time  to  Universal  Time  Coordinated
	      (UTC),  if  supported by the underlying OS. Otherwise no conver-
	      sion is done and Localtime is returned. Example:

	      >	erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}).
	      {{1996,11,6},{13,45,17}}

	      Failure: badarg if Localtime denotes an invalid date and time.

       erlang:localtime_to_universaltime(Localtime, IsDst) ->
					    Universaltime

	      Types:

		 Localtime = Universaltime = calendar:datetime()
		 IsDst = true |	false |	undefined

	      Converts local date and time to Universal	Time Coordinated (UTC)
	      as  erlang:localtime_to_universaltime/1,	but the	caller decides
	      if Daylight Saving Time is active.

	      If IsDst == true,	Localtime is during Daylight Saving  Time,  if
	      IsDst  ==	false it is not. If IsDst == undefined,	the underlying
	      OS can  guess,  which  is	 the  same  as	calling	 erlang:local-
	      time_to_universaltime(Localtime).

	      Examples:

	      >	erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, true).
	      {{1996,11,6},{12,45,17}}
	      >	erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, false).
	      {{1996,11,6},{13,45,17}}
	      >	erlang:localtime_to_universaltime({{1996,11,6},{14,45,17}}, undefined).
	      {{1996,11,6},{13,45,17}}

	      Failure: badarg if Localtime denotes an invalid date and time.

       make_ref() -> reference()

	      Returns  a  unique reference. The	reference is unique among con-
	      nected nodes.

	  Warning:
	      Known issue: When	a node is restarted multiple  times  with  the
	      same  node  name,	references created on a	newer node can be mis-
	      taken for	a reference created on an older	 node  with  the  same
	      node name.

       erlang:make_tuple(Arity,	InitialValue) -> tuple()

	      Types:

		 Arity = arity()
		 InitialValue =	term()

	      Creates  a  new tuple of the specified Arity, where all elements
	      are InitialValue,	for example:

	      >	erlang:make_tuple(4, []).
	      {[],[],[],[]}

       erlang:make_tuple(Arity,	DefaultValue, InitList)	-> tuple()

	      Types:

		 Arity = arity()
		 DefaultValue =	term()
		 InitList = [{Position :: integer() >= 1, term()}]

	      Creates a	tuple of size Arity, where each	element	has value  De-
	      faultValue,  and	then  fills in values from InitList. Each list
	      element in InitList must be a two-tuple, where the first element
	      is  a position in	the newly created tuple	and the	second element
	      is any term. If a	position occurs	more than once	in  the	 list,
	      the term corresponding to	the last occurrence is used. Example:

	      >	erlang:make_tuple(5, [], [{2,ignored},{5,zz},{2,aa}]).
	      {[],aa,[],[],zz}

       map_get(Key, Map) -> Value

	      Types:

		 Map = map()
		 Key = Value = any()

	      Returns value Value associated with Key if Map contains Key.

	      The  call	 fails	with  a	{badmap,Map} exception if Map is not a
	      map, or with a {badkey,Key} exception if no value	is  associated
	      with Key.

	      Example:

	      >	Key = 1337,
		Map = #{42 => value_two,1337 =>	"value one","a"	=> 1},
		map_get(Key,Map).
	      "value one"

       map_size(Map) ->	integer() >= 0

	      Types:

		 Map = map()

	      Returns  an  integer,  which is the number of key-value pairs in
	      Map, for example:

	      >	map_size(#{a=>1, b=>2, c=>3}).
	      3

	      Allowed in guard tests.

       erlang:match_spec_test(MatchAgainst, MatchSpec, Type) ->
				 TestResult

	      Types:

		 MatchAgainst =	[term()] | tuple()
		 MatchSpec = term()
		 Type =	table |	trace
		 TestResult =
		     {ok,   term(),   [return_trace],	[{error	  |   warning,
		 string()}]} |
		     {error, [{error | warning,	string()}]}

	      Tests  a	match  specification used in calls to ets:select/2 and
	      erlang:trace_pattern/3. The function tests both a	match specifi-
	      cation for "syntactic" correctness and runs the match specifica-
	      tion against the object. If the match specification contains er-
	      rors,  the  tuple	{error,	Errors}	is returned, where Errors is a
	      list of natural language descriptions of what was	wrong with the
	      match specification.

	      If  Type is table, the object to match against is	to be a	tuple.
	      The function then	returns	{ok,Result,[],Warnings}, where	Result
	      is  what would have been the result in a real ets:select/2 call,
	      or false if the match specification does not  match  the	object
	      tuple.

	      If  Type	is trace, the object to	match against is to be a list.
	      The function returns {ok,	Result,	Flags, Warnings}, where	Result
	      is one of	the following:

		* true if a trace message is to	be emitted

		* false	if a trace message is not to be	emitted

		* The message term to be appended to the trace message

	      Flags  is	 a  list containing all	the trace flags	to be enabled,
	      currently	this is	only return_trace.

	      This is a	useful debugging and test tool,	especially when	 writ-
	      ing complicated match specifications.

	      See also ets:test_ms/2.

       max(Term1, Term2) -> Maximum

	      Types:

		 Term1 = Term2 = Maximum = term()

	      Returns  the largest of Term1 and	Term2. If the terms are	equal,
	      Term1 is returned.

       erlang:md5(Data)	-> Digest

	      Types:

		 Data =	iodata()
		 Digest	= binary()

	      Computes an MD5 message digest from Data,	where  the  length  of
	      the digest is 128	bits (16 bytes). Data is a binary or a list of
	      small integers and binaries.

	      For more information about MD5, see  RFC 1321 - The MD5 Message-
	      Digest Algorithm.

	  Warning:
	      The  MD5	Message-Digest	Algorithm  is  not considered safe for
	      code-signing or software-integrity purposes.

       erlang:md5_final(Context) -> Digest

	      Types:

		 Context = Digest = binary()

	      Finishes the update of an	MD5 Context and	returns	 the  computed
	      MD5 message digest.

       erlang:md5_init() -> Context

	      Types:

		 Context = binary()

	      Creates  an  MD5	context,  to be	used in	the following calls to
	      md5_update/2.

       erlang:md5_update(Context, Data)	-> NewContext

	      Types:

		 Context = binary()
		 Data =	iodata()
		 NewContext = binary()

	      Update an	MD5 Context with Data and returns a NewContext.

       erlang:memory() -> [{Type, Size}]

	      Types:

		 Type =	memory_type()
		 Size =	integer() >= 0
		 memory_type() =
		     total |
		     processes |
		     processes_used |
		     system |
		     atom |
		     atom_used |
		     binary |
		     code |
		     ets

	      Returns a	list with information about memory  dynamically	 allo-
	      cated  by	 the  Erlang  emulator.	 Each  list element is a tuple
	      {Type, Size}. The	first element Type is an atom describing  mem-
	      ory type.	The second element Size	is the memory size in bytes.

	      Memory types:

		total:
		  The  total amount of memory currently	allocated. This	is the
		  same as the sum of the memory	size for processes and system.

		processes:
		  The total amount of memory currently allocated for  the  Er-
		  lang processes.

		processes_used:
		  The total amount of memory currently used by the Erlang pro-
		  cesses. This is part of the memory  presented	 as  processes
		  memory.

		system:
		  The  total amount of memory currently	allocated for the emu-
		  lator	that is	not directly related to	 any  Erlang  process.
		  Memory  presented  as	processes is not included in this mem-
		  ory. instrument(3) can be used to get	a more detailed	break-
		  down of what memory is part of this type.

		atom:
		  The  total  amount  of memory	currently allocated for	atoms.
		  This memory is part of the memory presented as  system  mem-
		  ory.

		atom_used:
		  The  total  amount  of memory	currently used for atoms. This
		  memory is part of the	memory presented as atom memory.

		binary:
		  The total amount of memory currently allocated for binaries.
		  This	memory	is part	of the memory presented	as system mem-
		  ory.

		code:
		  The total amount of memory currently	allocated  for	Erlang
		  code.	 This memory is	part of	the memory presented as	system
		  memory.

		ets:
		  The total amount of memory currently allocated for  ETS  ta-
		  bles.	 This memory is	part of	the memory presented as	system
		  memory.

		low:
		  Only on 64-bit halfword emulator. The	total amount of	memory
		  allocated in low memory areas	that are restricted to < 4 GB,
		  although the system can have more memory.

		  Can be removed in a future release of	the halfword emulator.

		maximum:
		  The maximum total amount of memory allocated since the  emu-
		  lator	 was started. This tuple is only present when the emu-
		  lator	is run with instrumentation.

		  For information on how to run	the emulator with instrumenta-
		  tion,	see instrument(3) and/or erl(1).

	  Note:
	      The  system value	is not complete. Some allocated	memory that is
	      to be part of this value is not.

	      When the emulator	is run with instrumentation, the system	 value
	      is  more accurate, but memory directly allocated for malloc (and
	      friends) is still	not part of the	system value. Direct calls  to
	      malloc are only done from	OS-specific runtime libraries and per-
	      haps from	user-implemented Erlang	drivers	that do	 not  use  the
	      memory allocation	functions in the driver	interface.

	      As the total value is the	sum of processes and system, the error
	      in system	propagates to the total	value.

	      The different amounts of memory that are summed are not gathered
	      atomically, which	introduces an error in the result.

	      The  different values have the following relation	to each	other.
	      Values beginning with an uppercase letter	is not part of the re-
	      sult.

	      total	 = processes + system
	      processes	 = processes_used + ProcessesNotUsed
	      system	 = atom	+ binary + code	+ ets +	OtherSystem
	      atom	 = atom_used + AtomNotUsed
	      RealTotal	 = processes + RealSystem
	      RealSystem = system + MissedSystem

	      More  tuples  in	the returned list can be added in a future re-
	      lease.

	  Note:
	      The total	value is supposed to be	the total amount of memory dy-
	      namically	 allocated by the emulator. Shared libraries, the code
	      of the emulator itself, and the emulator stacks are not supposed
	      to  be  included.	That is, the total value is not	supposed to be
	      equal to the total size of all pages mapped to the emulator.

	      Also, because of fragmentation and prereservation	of memory  ar-
	      eas,  the	size of	the memory segments containing the dynamically
	      allocated	memory blocks can be much larger than the  total  size
	      of the dynamically allocated memory blocks.

	  Note:
	      As  from	ERTS 5.6.4, erlang:memory/0 requires that all erts_al-
	      loc(3) allocators	are enabled (default behavior).

	      Failure: notsup if an erts_alloc(3) allocator has	been disabled.

       erlang:memory(Type :: memory_type()) -> integer() >= 0

       erlang:memory(TypeList :: [memory_type()]) ->
			[{memory_type(), integer() >= 0}]

	      Types:

		 memory_type() =
		     total |
		     processes |
		     processes_used |
		     system |
		     atom |
		     atom_used |
		     binary |
		     code |
		     ets

	      Returns the memory size in bytes allocated for  memory  of  type
	      Type.  The  argument  can	 also  be  specified as	a list of mem-
	      ory_type() atoms,	in which case a	corresponding  list  of	 {mem-
	      ory_type(), Size :: integer _= 0}	tuples is returned.

	  Note:
	      As  from	ERTS 5.6.4, erlang:memory/1 requires that all erts_al-
	      loc(3) allocators	are enabled (default behavior).

	      Failures:

		badarg:
		   If Type is not one of the memory types listed  in  the  de-
		  scription of erlang:memory/0.

		badarg:
		   If maximum is passed	as Type	and the	emulator is not	run in
		  instrumented mode.

		notsup:
		   If an erts_alloc(3) allocator has been disabled.

	      See also erlang:memory/0.

       min(Term1, Term2) -> Minimum

	      Types:

		 Term1 = Term2 = Minimum = term()

	      Returns the smallest of Term1 and	Term2. If the terms are	equal,
	      Term1 is returned.

       module_loaded(Module) ->	boolean()

	      Types:

		 Module	= module()

	      Returns true if the module Module	is loaded, otherwise false. It
	      does not attempt to load the module.

	  Warning:
	      This BIF is intended for the code	server (see  code(3))  and  is
	      not to be	used elsewhere.

       monitor(Type :: process,	Item ::	monitor_process_identifier()) ->
		  MonitorRef

       monitor(Type :: port, Item :: monitor_port_identifier())	->
		  MonitorRef

       monitor(Type :: time_offset, Item :: clock_service) -> MonitorRef

	      Types:

		 MonitorRef = reference()
		 registered_name() = atom()
		 registered_process_identifier() =
		     registered_name() | {registered_name(), node()}
		 monitor_process_identifier() =
		     pid() | registered_process_identifier()
		 monitor_port_identifier() = port() | registered_name()

	      Sends a monitor request of type Type to the entity identified by
	      Item. If the monitored entity does not exist or it changes moni-
	      tored state, the caller of monitor/2 is notified by a message on
	      the following format:

	      {Tag, MonitorRef,	Type, Object, Info}

	  Note:
	      The monitor request is an	asynchronous signal. That is, it takes
	      time before the signal reaches its destination.

	      Type  can	 be  one  of  the  following  atoms:  process, port or
	      time_offset.

	      A	process	or port	monitor	is triggered only once,	after that  it
	      is  removed  from	 both monitoring process and the monitored en-
	      tity. Monitors are fired when the	monitored process or port ter-
	      minates,	does  not  exist  at the moment	of creation, or	if the
	      connection to it is lost.	If the connection to it	is lost, we do
	      not  know	 if it still exists. The monitoring is also turned off
	      when demonitor/1 is called.

	      A	process	or port	monitor	by name	resolves the RegisteredName to
	      pid()  or	 port()	 only once at the moment of monitor instantia-
	      tion, later changes to the name registration will	not affect the
	      existing monitor.

	      When a process or	port monitor is	triggered, a 'DOWN' message is
	      sent that	has the	following pattern:

	      {'DOWN', MonitorRef, Type, Object, Info}

	      In the monitor message MonitorRef	and Type are the same  as  de-
	      scribed earlier, and:

		Object:
		  The  monitored entity, which triggered the event. When moni-
		  toring a local process or port, Object will be equal to  the
		  pid()	 or  port()  that was being monitored. When monitoring
		  process or port by name, Object  will	 have  format  {Regis-
		  teredName,  Node} where RegisteredName is the	name which has
		  been used with monitor/2 call	and Node is  local  or	remote
		  node name (for ports monitored by name, Node is always local
		  node name).

		Info:
		  Either the exit reason of the	process,  noproc  (process  or
		  port	did not	exist at the time of monitor creation),	or no-
		  connection (no connection to the node	 where	the  monitored
		  process resides).

		Monitoring a process:
		  Creates  monitor  between  the  current  process and another
		  process identified by	Item, which can	be a pid()  (local  or
		  remote),  an atom RegisteredName or a	tuple {RegisteredName,
		  Node}	for a registered process, located elsewhere.

	    Note:
		Before ERTS 10.0 (OTP 21.0), monitoring	a process  could  fail
		with  badarg  if  the monitored	process	resided	on a primitive
		node (such  as	erl_interface  or  jinterface),	 where	remote
		process	monitoring is not implemented.

		Now, such a call to monitor will instead succeed and a monitor
		is created. But	the monitor will only  supervise  the  connec-
		tion.  That is,	a {'DOWN', _, process, _, noconnection}	is the
		only message that may be received, as the primitive node  have
		no way of reporting the	status of the monitored	process.

		Monitoring a port:
		  Creates monitor between the current process and a port iden-
		  tified by Item, which	can be a port()	(only local), an  atom
		  RegisteredName  or a tuple {RegisteredName, Node} for	a reg-
		  istered port,	located	on this	node. Note,  that  attempt  to
		  monitor a remote port	will result in badarg.

		Monitoring a time_offset:
		  Monitors  changes  in	 time  offset between Erlang monotonic
		  time and Erlang system time. One valid Item exists in	combi-
		  nation with the time_offset Type, namely the atom clock_ser-
		  vice.	Notice that the	atom clock_service is not  the	regis-
		  tered	 name of a process. In this case it serves as an iden-
		  tifier of the	runtime	system internal	clock service at  cur-
		  rent runtime system instance.

		  The  monitor	is  triggered when the time offset is changed.
		  This either if the time offset value is changed, or  if  the
		  offset is changed from preliminary to	final during finaliza-
		  tion of the time offset when the single time	warp  mode  is
		  used.	When a change from preliminary to final	time offset is
		  made,	the monitor is triggered once  regardless  of  whether
		  the time offset value	was changed or not.

		  If  the  runtime system is in	multi time warp	mode, the time
		  offset is changed when the runtime system detects  that  the
		  OS  system  time  has	changed. The runtime system does, how-
		  ever,	not detect this	immediately when  it  occurs.  A  task
		  checking  the	 time  offset is scheduled to execute at least
		  once a minute, so under normal operation this	is to  be  de-
		  tected  within  a  minute, but during	heavy load it can take
		  longer time.

		  The monitor is not automatically removed after it  has  been
		  triggered.  That  is,	 repeated  changes  of the time	offset
		  trigger the monitor repeatedly.

		  When the monitor is triggered	a 'CHANGE' message is sent  to
		  the monitoring process. A 'CHANGE' message has the following
		  pattern:

		{'CHANGE', MonitorRef, Type, Item, NewTimeOffset}

		  where	MonitorRef, Type, and Item are the same	 as  described
		  above, and NewTimeOffset is the new time offset.

		  When	the 'CHANGE' message has been received you are guaran-
		  teed not to retrieve the old time offset  when  calling  er-
		  lang:time_offset().  Notice  that you	can observe the	change
		  of the time offset when calling erlang:time_offset()	before
		  you get the 'CHANGE' message.

	      Making  several calls to monitor/2 for the same Item and/or Type
	      is not an	error; it results in as	 many  independent  monitoring
	      instances.

	      The  monitor  functionality is expected to be extended. That is,
	      other Types and Items are	expected to be supported in  a	future
	      release.

	  Note:
	      If or when monitor/2 is extended,	other possible values for Tag,
	      Object, and Info in the monitor message will be introduced.

       monitor_node(Node, Flag)	-> true

	      Types:

		 Node =	node()
		 Flag =	boolean()

	      Monitor the status of the	node Node. If Flag is true, monitoring
	      is turned	on. If Flag is false, monitoring is turned off.

	      Making  several  calls  to monitor_node(Node, true) for the same
	      Node is not an error; it results in as many independent monitor-
	      ing instances.

	      If Node fails or does not	exist, the message {nodedown, Node} is
	      delivered	to the process.	If a process has  made	two  calls  to
	      monitor_node(Node,  true)	and Node terminates, two nodedown mes-
	      sages are	delivered to the process. If there is no connection to
	      Node,  an	 attempt is made to create one.	If this	fails, a node-
	      down message is delivered.

	      Nodes connected through hidden connections can be	 monitored  as
	      any other	nodes.

	      Failure: badarg if the local node	is not alive.

       erlang:monitor_node(Node, Flag, Options)	-> true

	      Types:

		 Node =	node()
		 Flag =	boolean()
		 Options = [Option]
		 Option	= allow_passive_connect

	      Behaves  as monitor_node/2 except	that it	allows an extra	option
	      to be specified, namely allow_passive_connect. This  option  al-
	      lows  the	BIF to wait the	normal network connection time-out for
	      the monitored node to connect itself, even if it cannot  be  ac-
	      tively  connected	 from  this node (that is, it is blocked). The
	      state where this can be useful can only be achieved by using the
	      Kernel  option  dist_auto_connect	 once.	If  that option	is not
	      used, option allow_passive_connect has no	effect.

	  Note:
	      Option allow_passive_connect is used internally  and  is	seldom
	      needed in	applications where the network topology	and the	Kernel
	      options in effect	are known in advance.

	      Failure: badarg if the local node	is not	alive  or  the	option
	      list is malformed.

       erlang:monotonic_time() -> integer()

	      Returns  the  current Erlang monotonic time in native time unit.
	      This is a	monotonically increasing time since  some  unspecified
	      point in time.

	  Note:
	      This  is	a   monotonically increasing time, but not a  strictly
	      monotonically increasing time. That is, consecutive calls	to er-
	      lang:monotonic_time/0 can	produce	the same result.

	      Different	 runtime  system instances will	use different unspeci-
	      fied points in time as base for their Erlang  monotonic  clocks.
	      That  is,	it is pointless	comparing monotonic times from differ-
	      ent runtime system instances. Different runtime system instances
	      can also place this unspecified point in time different relative
	      runtime system start. It can be placed in	the  future  (time  at
	      start  is	 a negative value), the	past (time at start is a posi-
	      tive value), or the runtime  system  start  (time	 at  start  is
	      zero).  The  monotonic  time  at runtime system start can	be re-
	      trieved by calling erlang:system_info(start_time).

       erlang:monotonic_time(Unit) -> integer()

	      Types:

		 Unit =	time_unit()

	      Returns the current Erlang monotonic  time  converted  into  the
	      Unit passed as argument.

	      Same     as     calling	 erlang:convert_time_unit(erlang:mono-
	      tonic_time(), native, Unit), however optimized for commonly used
	      Units.

       erlang:nif_error(Reason)	-> no_return()

	      Types:

		 Reason	= term()

	      Works  exactly  like  error/1, but Dialyzer thinks that this BIF
	      will return an arbitrary term. When used in a stub function  for
	      a	 NIF  to  generate  an	exception  when	the NIF	library	is not
	      loaded, Dialyzer does not	generate false warnings.

       erlang:nif_error(Reason,	Args) -> no_return()

	      Types:

		 Reason	= term()
		 Args =	[term()]

	      Works exactly like error/2, but Dialyzer thinks  that  this  BIF
	      will  return an arbitrary	term. When used	in a stub function for
	      a	NIF to generate	an exception  when  the	 NIF  library  is  not
	      loaded, Dialyzer does not	generate false warnings.

       node() -> Node

	      Types:

		 Node =	node()

	      Returns  the  name  of the local node. If	the node is not	alive,
	      nonode@nohost is returned	instead.

	      Allowed in guard tests.

       node(Arg) -> Node

	      Types:

		 Arg = pid() | port() |	reference()
		 Node =	node()

	      Returns the node where Arg originates.  Arg  can	be  a  process
	      identifier,  a  reference,  or  a	port. If the local node	is not
	      alive, nonode@nohost is returned.

	      Allowed in guard tests.

       nodes() -> Nodes

	      Types:

		 Nodes = [node()]

	      Returns a	list of	all visible nodes in the  system,  except  the
	      local node. Same as nodes(visible).

       nodes(Arg) -> Nodes

	      Types:

		 Arg = NodeType	| [NodeType]
		 NodeType = visible | hidden | connected | this	| known
		 Nodes = [node()]

	      Returns a	list of	nodes according	to the argument	specified. The
	      returned result, when the	argument is a list,  is	 the  list  of
	      nodes satisfying the disjunction(s) of the list elements.

	      NodeTypes:

		visible:
		  Nodes	connected to this node through normal connections.

		hidden:
		  Nodes	connected to this node through hidden connections.

		connected:
		  All nodes connected to this node.

		this:
		  This node.

		known:
		  Nodes	 that are known	to this	node. That is, connected nodes
		  and nodes referred to	by process identifiers,	 port  identi-
		  fiers, and references	located	on this	node. The set of known
		  nodes	is garbage collected. Notice that this garbage collec-
		  tion	can  be	delayed. For more information, see erlang:sys-
		  tem_info(delayed_node_table_gc).

	      Some equalities:	[node()]  =  nodes(this),  nodes(connected)  =
	      nodes([visible, hidden]),	and nodes() = nodes(visible).

       now() ->	Timestamp

	      Types:

		 Timestamp = timestamp()
		 timestamp() =
		     {MegaSecs :: integer() >= 0,
		      Secs :: integer()	>= 0,
		      MicroSecs	:: integer() >=	0}

	  Warning:
	      This function is deprecated. Do not use it.

	      For  more	 information,  see section Time	and Time Correction in
	      the User's Guide.	Specifically,  section	 Dos  and  Dont's  de-
	      scribes what to use instead of erlang:now/0.

	      Returns  the  tuple  {MegaSecs,  Secs,  MicroSecs}, which	is the
	      elapsed time since 00:00 GMT, January 1, 1970  (zero  hour),  if
	      provided	by  the	 underlying  OS. Otherwise some	other point in
	      time is chosen. It is also guaranteed that the  following	 calls
	      to  this	BIF  return continuously increasing values. Hence, the
	      return value from	erlang:now/0 can be used  to  generate	unique
	      time  stamps. If it is called in a tight loop on a fast machine,
	      the time of the node can become skewed.

	      Can only be used to check	the local time of day if the time-zone
	      information of the underlying OS is properly configured.

       open_port(PortName, PortSettings) -> port()

	      Types:

		 PortName =
		     {spawn, Command ::	string() | binary()} |
		     {spawn_driver, Command :: string()	| binary()} |
		     {spawn_executable,	FileName :: file:name()} |
		     {fd, In ::	integer() >= 0,	Out :: integer() >= 0}
		 PortSettings =	[Opt]
		 Opt =
		     {packet, N	:: 1 | 2 | 4} |
		     stream |
		     {line, L :: integer() >= 0} |
		     {cd, Dir :: string() | binary()} |
		     {env,
		      Env ::
			  [{Name :: os:env_var_name(),
			    Val	:: os:env_var_value() |	false}]} |
		     {args, [string() |	binary()]} |
		     {arg0, string() | binary()} |
		     exit_status |
		     use_stdio |
		     nouse_stdio |
		     stderr_to_stdout |
		     in	|
		     out |
		     binary |
		     eof |
		     {parallelism, Boolean :: boolean()} |
		     hide

	      Returns  a port identifier as the	result of opening a new	Erlang
	      port. A port can be seen as an external Erlang process.

	      The name of the executable as well as the	arguments specifed  in
	      cd, env, args, and arg0 are subject to Unicode filename transla-
	      tion if the system is running in Unicode filename	mode. To avoid
	      translation  or  to  force,  for	example	UTF-8, supply the exe-
	      cutable and/or arguments as a binary in  the  correct  encoding.
	      For  details,  see  the  module  file(3),	 the function file:na-
	      tive_name_encoding/0 in Kernel, and the Using Unicode in	Erlang
	      User's Guide.

	  Note:
	      The  characters in the name (if specified	as a list) can only be
	      >	255 if the Erlang virtual machine is started in	Unicode	 file-
	      name  translation	 mode. Otherwise the name of the executable is
	      limited to the ISO Latin-1 character set.

	      PortNames:

		{spawn,	Command}:
		  Starts an external program. Command is the name of  the  ex-
		  ternal  program  to  be run. Command runs outside the	Erlang
		  work space unless an Erlang driver with the name Command  is
		  found.  If  found,  that driver is started. A	driver runs in
		  the Erlang work space, which means that it  is  linked  with
		  the Erlang runtime system.

		  For  external	 programs,  PATH is searched (or an equivalent
		  method is used to find programs, depending on	the OS).  This
		  is  done  by	invoking  the  shell on	certain	platforms. The
		  first	space-separated	token of the command is	considered  as
		  the  name  of	 the executable	(or driver). This (among other
		  things) makes	this option unsuitable	for  running  programs
		  with	spaces	in  filenames or directory names. If spaces in
		  executable filenames	are  desired,  use  {spawn_executable,
		  Command} instead.

		{spawn_driver, Command}:
		  Works	 like  {spawn, Command}, but demands the first (space-
		  separated) token of the command to be	the name of  a	loaded
		  driver.  If no driver	with that name is loaded, a badarg er-
		  ror is raised.

		{spawn_executable, FileName}:
		  Works	like {spawn, FileName},	but only  runs	external  exe-
		  cutables.  FileName  in its whole is used as the name	of the
		  executable, including	any spaces. If	arguments  are	to  be
		  passed, the PortSettings args	and arg0 can be	used.

		  The shell is usually not invoked to start the	program, it is
		  executed directly. PATH (or equivalent) is not searched.  To
		  find a program in PATH to execute, use os:find_executable/1.

		  Only	if a shell script or .bat file is executed, the	appro-
		  priate command interpreter is	invoked	implicitly, but	 there
		  is  still  no	 command-argument  expansion  or implicit PATH
		  search.

		  If FileName cannot be	run, an	 error	exception  is  raised,
		  with	the  POSIX  error code as the reason. The error	reason
		  can differ between OSs. Typically the	error enoent is	raised
		  when	an  attempt is made to run a program that is not found
		  and eacces is	raised when the	specified  file	 is  not  exe-
		  cutable.

		{fd, In, Out}:
		  Allows an Erlang process to access any currently opened file
		  descriptors used by Erlang. The file descriptor  In  can  be
		  used	for  standard  input,  and the file descriptor Out for
		  standard output. It is only used for various servers in  the
		  Erlang OS (shell and user). Hence, its use is	limited.

	      PortSettings  is a list of settings for the port.	The valid set-
	      tings are	as follows:

		{packet, N}:
		  Messages are preceded	by their length, sent in N bytes, with
		  the  most significant	byte first. The	valid values for N are
		  1, 2,	and 4.

		stream:
		  Output messages are sent without packet lengths. A  user-de-
		  fined	 protocol  must	be used	between	the Erlang process and
		  the external object.

		{line, L}:
		  Messages are delivered on a per line basis. Each  line  (de-
		  limited  by  the OS-dependent	newline	sequence) is delivered
		  in a single message.	The  message  data  format  is	{Flag,
		  Line},  where	Flag is	eol or noeol, and Line is the data de-
		  livered (without the newline sequence).

		  L specifies the maximum line length in bytes.	 Lines	longer
		  than	this are delivered in more than	one message, with Flag
		  set to noeol for all but the last message. If	end of file is
		  encountered  anywhere	else than immediately following	a new-
		  line sequence, the last line is also delivered with Flag set
		  to  noeol.  Otherwise	 lines	are delivered with Flag	set to
		  eol.

		  The {packet, N} and {line, L}	settings are  mutually	exclu-
		  sive.

		{cd, Dir}:
		  Only valid for {spawn, Command} and {spawn_executable, File-
		  Name}. The external program starts using Dir as its  working
		  directory. Dir must be a string.

		{env, Env}:
		  Types:
		  Name = os:env_var_name()
		  Val =	os:env_var_value() | false
		  Env =	[{Name,	Val}]

		  Only	valid  for  {spawn,  Command},	and {spawn_executable,
		  FileName}. The environment of	the  started  process  is  ex-
		  tended using the environment specifications in Env.

		  Env is to be a list of tuples	{Name, Val}, where Name	is the
		  name of an environment variable, and Val is the value	it  is
		  to  have in the spawned port process.	Both Name and Val must
		  be strings. The one exception	is Val being  the  atom	 false
		  (in  analogy with os:getenv/1, which removes the environment
		  variable.

		  For information about	encoding requirements, see  documenta-
		  tion of the types for	Name and Val.

		{args, [ string() | binary() ]}:
		  Only	valid  for  {spawn_executable, FileName} and specifies
		  arguments to the executable. Each argument is	specified as a
		  separate string and (on Unix)	eventually ends	up as one ele-
		  ment each in the argument vector. On other platforms,	a sim-
		  ilar behavior	is mimicked.

		  The  arguments are not expanded by the shell before they are
		  supplied to the executable. Most  notably  this  means  that
		  file	wildcard expansion does	not occur. To expand wildcards
		  for the arguments, use filelib:wildcard/1. Notice that  even
		  if  the  program  is	a  Unix	shell script, meaning that the
		  shell	ultimately is invoked, wildcard	expansion does not oc-
		  cur,	and  the  script  is provided with the untouched argu-
		  ments. On Windows, wildcard expansion	is always  up  to  the
		  program itself, therefore this is not	an issue.

		  The  executable  name	 (also	known as argv[0]) is not to be
		  specified in this list. The proper executable	name is	 auto-
		  matically used as argv[0], where applicable.

		  If  you explicitly want to set the program name in the argu-
		  ment vector, option arg0 can be used.

		{arg0, string()	| binary()}:
		  Only valid for {spawn_executable, FileName}  and  explicitly
		  specifies  the  program  name	 argument when running an exe-
		  cutable. This	can in some circumstances, on some OSs,	be de-
		  sirable.  How	the program responds to	this is	highly system-
		  dependent and	no specific effect is guaranteed.

		exit_status:
		  Only valid for {spawn, Command}, where Command refers	to  an
		  external program, and	for {spawn_executable, FileName}.

		  When	the  external  process	connected to the port exits, a
		  message of the form {Port,{exit_status,Status}} is  sent  to
		  the  connected  process,  where Status is the	exit status of
		  the external process.	If the program	aborts	on  Unix,  the
		  same	convention is used as the shells do (that is, 128+sig-
		  nal).

		  If option eof	 is  specified	also,  the  messages  eof  and
		  exit_status appear in	an unspecified order.

		  If  the  port	program	closes its stdout without exiting, op-
		  tion exit_status does	not work.

		use_stdio:
		  Only valid for {spawn, Command} and {spawn_executable, File-
		  Name}.  It  allows  the  standard input and output (file de-
		  scriptors 0 and 1) of	the spawned (Unix) process for	commu-
		  nication with	Erlang.

		nouse_stdio:
		  The  opposite	of use_stdio. It uses file descriptors 3 and 4
		  for communication with Erlang.

		stderr_to_stdout:
		  Affects ports	to external  programs.	The  executed  program
		  gets its standard error file redirected to its standard out-
		  put file. stderr_to_stdout and nouse_stdio are mutually  ex-
		  clusive.

		overlapped_io:
		  Affects  ports  to  external	programs  on Windows only. The
		  standard input and standard output handles of	the port  pro-
		  gram	are,  if  this	option	is  supplied, opened with flag
		  FILE_FLAG_OVERLAPPED,	so that	 the  port  program  can  (and
		  must)	do overlapped I/O on its standard handles. This	is not
		  normally the case for	simple port programs, but an option of
		  value	 for  the experienced Windows programmer. On all other
		  platforms, this option is silently discarded.

		in:
		  The port can only be used for	input.

		out:
		  The port can only be used for	output.

		binary:
		  All I/O from the port	is binary data objects as  opposed  to
		  lists	of bytes.

		eof:
		  The  port  is	not closed at the end of the file and does not
		  produce an exit signal.  Instead,  it	 remains  open	and  a
		  {Port, eof} message is sent to the process holding the port.

		hide:
		  When	running	 on Windows, suppresses	creation of a new con-
		  sole window when spawning the	port program. (This option has
		  no effect on other platforms.)

		{parallelism, Boolean}:

		  Sets	scheduler  hint	 for port parallelism. If set to true,
		  the virtual machine schedules	port tasks; when doing so,  it
		  improves  parallelism	 in  the  system. If set to false, the
		  virtual machine tries	to perform port	tasks immediately, im-
		  proving  latency  at the expense of parallelism. The default
		  can be set at	system startup by passing  command-line	 argu-
		  ment +spp to erl(1).

	      Default  is  stream for all port types and use_stdio for spawned
	      ports.

	      Failure: if the port  cannot  be	opened,	 the  exit  reason  is
	      badarg,  system_limit, or	the POSIX error	code that most closely
	      describes	the error, or einval if	no POSIX code is appropriate:

		badarg:
		  Bad input arguments to open_port.

		system_limit:
		  All available	ports in the Erlang emulator are in use.

		enomem:
		  Not enough memory to create the port.

		eagain:
		  No more available OS processes.

		enametoolong:
		  Too long external command.

		emfile:
		  No more available file descriptors (for the OS process  that
		  the Erlang emulator runs in).

		enfile:
		  Full file table (for the entire OS).

		eacces:
		  Command  specified  in  {spawn_executable, Command} does not
		  point	out an executable file.

		enoent:
		  FileName specified in	{spawn_executable, FileName} does  not
		  point	out an existing	file.

	      During  use of a port opened using {spawn, Name},	{spawn_driver,
	      Name}, or	{spawn_executable, Name}, errors arising when  sending
	      messages	to it are reported to the owning process using signals
	      of the form {'EXIT', Port, PosixCode}. For the  possible	values
	      of PosixCode, see	file(3).

	      The  maximum  number  of ports that can be open at the same time
	      can be configured	by passing command-line	flag +Q	to erl(1).

       erlang:phash(Term, Range) -> Hash

	      Types:

		 Term =	term()
		 Range = Hash =	integer() >= 1
		   Range = 1..2^32, Hash = 1..Range

	      Portable hash function that gives	the same hash for the same Er-
	      lang  term  regardless  of machine architecture and ERTS version
	      (the BIF was introduced in ERTS 4.9.1.1).	The function returns a
	      hash value for Term within the range 1..Range. The maximum value
	      for Range	is 2^32.

       erlang:phash2(Term) -> Hash

       erlang:phash2(Term, Range) -> Hash

	      Types:

		 Term =	term()
		 Range = integer() >= 1
		   1..2^32
		 Hash =	integer() >= 0
		   0..Range-1

	      Portable hash function that gives	the same hash for the same Er-
	      lang  term  regardless  of machine architecture and ERTS version
	      (the BIF was introduced in ERTS 5.2).  The  function  returns  a
	      hash  value  for	Term  within the range 0..Range-1. The maximum
	      value for	Range is 2^32. When without argument Range, a value in
	      the range	0..2^27-1 is returned.

	      This  BIF	is always to be	used for hashing terms.	It distributes
	      small integers better than phash/2, and it is faster for bignums
	      and binaries.

	      Notice  that the range 0..Range-1	is different from the range of
	      phash/2, which is	1..Range.

       pid_to_list(Pid)	-> string()

	      Types:

		 Pid = pid()

	      Returns a	string corresponding to	 the  text  representation  of
	      Pid.

       erlang:port_call(Port, Operation, Data) -> term()

	      Types:

		 Port =	port() | atom()
		 Operation = integer()
		 Data =	term()

	      Performs	a synchronous call to a	port. The meaning of Operation
	      and Data depends on the port, that is, on	the port  driver.  Not
	      all port drivers support this feature.

	      Port is a	port identifier, referring to a	driver.

	      Operation	is an integer, which is	passed on to the driver.

	      Data  is	any Erlang term. This data is converted	to binary term
	      format and sent to the port.

	      Returns a	term from the driver. The meaning of the returned data
	      also depends on the port driver.

	      Failures:

		badarg:
		   If Port is not an identifier	of an open port, or the	regis-
		  tered	name of	an open	port. If the calling process was  pre-
		  viously  linked  to the closed port, identified by Port, the
		  exit signal from the port is guaranteed to be	delivered  be-
		  fore this badarg exception occurs.

		badarg:
		   If Operation	does not fit in	a 32-bit integer.

		badarg:
		   If the port driver does not support synchronous control op-
		  erations.

		badarg:
		  If the port driver so	decides	for any	reason (probably some-
		  thing	wrong with Operation or	Data).

	    Warning:
		Do  not	call port_call with an unknown Port identifier and ex-
		pect badarg exception. Any undefined behavior is possible (in-
		cluding	 node  crash)  depending on how	the port driver	inter-
		prets the supplied arguments.

       port_close(Port)	-> true

	      Types:

		 Port =	port() | atom()

	      Closes an	open port. Roughly the same as Port ! {self(),	close}
	      except  for  the	error behavior (see below), being synchronous,
	      and that the port	 does  not  reply  with	 {Port,	 closed}.  Any
	      process  can  close  a port with port_close/1, not only the port
	      owner (the connected process). If	the calling process is	linked
	      to the port identified by	Port, the exit signal from the port is
	      guaranteed to be delivered before	port_close/1 returns.

	      For comparison: Port ! {self(), close} only fails	with badarg if
	      Port  does not refer to a	port or	a process. If Port is a	closed
	      port, nothing happens. If	Port is	an open	port and  the  calling
	      process  is the port owner, the port replies with	{Port, closed}
	      when all buffers have been flushed and the port  really  closes.
	      If  the  calling	process	 is not	the port owner,	the port owner
	      fails with badsig.

	      Notice that any process can close	a  port	 using	Port  !	 {Por-
	      tOwner, close} as	if it itself was the port owner, but the reply
	      always goes to the port owner.

	      As from Erlang/OTP R16, Port ! {PortOwner, close}	is truly asyn-
	      chronous.	 Notice	that this operation has	always been documented
	      as an asynchronous operation, while the  underlying  implementa-
	      tion  has	 been synchronous. port_close/1	is however still fully
	      synchronous because of its error behavior.

	      Failure: badarg if Port is not an	identifier of an open port, or
	      the  registered name of an open port. If the calling process was
	      previously linked	to the closed port, identified	by  Port,  the
	      exit  signal  from the port is guaranteed	to be delivered	before
	      this badarg exception occurs.

       port_command(Port, Data)	-> true

	      Types:

		 Port =	port() | atom()
		 Data =	iodata()

	      Sends data to a port.  Same  as  Port  !	{PortOwner,  {command,
	      Data}}  except for the error behavior and	being synchronous (see
	      below). Any process can send data	to a port with port_command/2,
	      not only the port	owner (the connected process).

	      For  comparison:	Port ! {PortOwner, {command, Data}} only fails
	      with badarg if Port does not refer to a port or  a  process.  If
	      Port  is	a  closed  port, the data message disappears without a
	      sound. If	Port is	open and the calling process is	not  the  port
	      owner,  the  port	 owner fails with badsig. The port owner fails
	      with badsig also if Data is an invalid I/O list.

	      Notice that any process can send to a port using	Port  !	 {Por-
	      tOwner, {command,	Data}} as if it	itself was the port owner.

	      If  the port is busy, the	calling	process	is suspended until the
	      port is not busy any more.

	      As from Erlang/OTP R16, Port ! {PortOwner, {command,  Data}}  is
	      truly  asynchronous.  Notice that	this operation has always been
	      documented as an asynchronous operation,	while  the  underlying
	      implementation  has  been	synchronous. port_command/2 is however
	      still fully synchronous because of its error behavior.

	      Failures:

		badarg:
		  If Port is not an identifier of an open port,	or the	regis-
		  tered	 name of an open port. If the calling process was pre-
		  viously linked to the	closed port, identified	by  Port,  the
		  exit	signal from the	port is	guaranteed to be delivered be-
		  fore this badarg exception occurs.

		badarg:
		  If Data is an	invalid	I/O list.

	  Warning:
	      Do not send data to an unknown port. Any undefined  behavior  is
	      possible (including node crash) depending	on how the port	driver
	      interprets the data.

       port_command(Port, Data,	OptionList) -> boolean()

	      Types:

		 Port =	port() | atom()
		 Data =	iodata()
		 Option	= force	| nosuspend
		 OptionList = [Option]

	      Sends data  to  a	 port.	port_command(Port,  Data,  [])	equals
	      port_command(Port, Data).

	      If  the  port  command  is aborted, false	is returned, otherwise
	      true.

	      If the port is busy, the calling process is suspended until  the
	      port is not busy anymore.

	      Options:

		force:
		  The  calling	process	 is not	suspended if the port is busy,
		  instead the port command is forced through. The  call	 fails
		  with	a  notsup exception if the driver of the port does not
		  support  this.  For  more  information,  see	 driver	  flag
		  ![CDATA[ERL_DRV_FLAG_SOFT_BUSY]].

		nosuspend:
		  The  calling	process	 is not	suspended if the port is busy,
		  instead the port command is aborted and false	is returned.

	  Note:
	      More options can be added	in a future release.

	      Failures:

		badarg:
		   If Port is not an identifier	of an open port, or the	regis-
		  tered	 name of an open port. If the calling process was pre-
		  viously linked to the	closed port, identified	by  Port,  the
		  exit	signal from the	port is	guaranteed to be delivered be-
		  fore this badarg exception occurs.

		badarg:
		   If Data is an invalid I/O list.

		badarg:
		   If OptionList is an invalid option list.

		notsup:
		   If option force has been passed, but	the driver of the port
		  does not allow forcing through a busy	port.

	  Warning:
	      Do  not  send data to an unknown port. Any undefined behavior is
	      possible (including node crash) depending	on how the port	driver
	      interprets the data.

       port_connect(Port, Pid) -> true

	      Types:

		 Port =	port() | atom()
		 Pid = pid()

	      Sets  the	 port  owner  (the connected port) to Pid. Roughly the
	      same as Port ! {Owner, {connect, Pid}} except for	the following:

		* The error behavior differs, see below.

		* The port does	not reply with {Port,connected}.

		* port_connect/1 is synchronous, see below.

		* The new port owner gets linked to the	port.

	      The old port owner stays linked to the port and  must  call  un-
	      link(Port)  if this is not desired. Any process can set the port
	      owner to be any process with port_connect/2.

	      For comparison: Port ! {self(), {connect,	Pid}} only fails  with
	      badarg if	Port does not refer to a port or a process. If Port is
	      a	closed port, nothing happens. If Port is an open port and  the
	      calling  process is the port owner, the port replies with	{Port,
	      connected} to the	old port owner.	Notice that the	old port owner
	      is still linked to the port, while the new is not. If Port is an
	      open port	and the	calling	process	is not	the  port  owner,  the
	      port  owner  fails with badsig. The port owner fails with	badsig
	      also if Pid is not an existing local process identifier.

	      Notice that any process can set the  port	 owner	using  Port  !
	      {PortOwner,  {connect, Pid}} as if it itself was the port	owner,
	      but the reply always goes	to the port owner.

	      As from Erlang/OTP R16, Port ! {PortOwner,  {connect,  Pid}}  is
	      truly  asynchronous.  Notice that	this operation has always been
	      documented as an asynchronous operation,	while  the  underlying
	      implementation  has  been	synchronous. port_connect/2 is however
	      still fully synchronous because of its error behavior.

	      Failures:

		badarg:
		   If Port is not an identifier	of an open port, or the	regis-
		  tered	 name of an open port. If the calling process was pre-
		  viously linked to the	closed port, identified	by  Port,  the
		  exit	signal from the	port is	guaranteed to be delivered be-
		  fore this badarg exception occurs.

		badarg:
		  If the process identified by Pid is not  an  existing	 local
		  process.

       port_control(Port, Operation, Data) -> iodata() | binary()

	      Types:

		 Port =	port() | atom()
		 Operation = integer()
		 Data =	iodata()

	      Performs	a synchronous control operation	on a port. The meaning
	      of Operation and Data depends on the port, that is, on the  port
	      driver. Not all port drivers support this	control	feature.

	      Returns a	list of	integers in the	range 0..255, or a binary, de-
	      pending on the port driver. The meaning  of  the	returned  data
	      also depends on the port driver.

	      Failures:

		badarg:
		   If  Port  is	 not an	open port or the registered name of an
		  open port.

		badarg:
		   If Operation	cannot fit in a	32-bit integer.

		badarg:
		   If the port driver does not support synchronous control op-
		  erations.

		badarg:
		   If  the  port  driver  so  decides for any reason (probably
		  something wrong with Operation or Data).

	    Warning:
		Do not call port_control/3 with	an unknown Port	identifier and
		expect	badarg	exception.  Any	undefined behavior is possible
		(including node	crash) depending on how	the port driver	inter-
		prets the supplied arguments.

       erlang:port_info(Port) -> Result

	      Types:

		 Port =	port() | atom()
		 ResultItem =
		     {registered_name, RegisteredName :: atom()} |
		     {id, Index	:: integer() >=	0} |
		     {connected, Pid ::	pid()} |
		     {links, Pids :: [pid()]} |
		     {name, String :: string()}	|
		     {input, Bytes :: integer()	>= 0} |
		     {output, Bytes :: integer() >= 0} |
		     {os_pid, OsPid :: integer() >= 0 |	undefined}
		 Result	= [ResultItem] | undefined

	      Returns a	list containing	tuples with information	about Port, or
	      undefined	if the port is not open. The order of  the  tuples  is
	      undefined,  and all the tuples are not mandatory.	If the port is
	      closed and the calling process  was  previously  linked  to  the
	      port,  the  exit signal from the port is guaranteed to be	deliv-
	      ered before port_info/1 returns undefined.

	      The result contains information about the	following Items:

		* registered_name (if the port has a registered	name)

		* id

		* connected

		* links

		* name

		* input

		* output

	      For more information about the different Items, see port_info/2.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       erlang:port_info(Port, Item :: connected) ->
			   {connected, Pid} | undefined

	      Types:

		 Port =	port() | atom()
		 Pid = pid()

	      Pid  is  the  process identifier of the process connected	to the
	      port.

	      If the port identified by	Port is	not  open,  undefined  is  re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure:	badarg	if  Port is not	a local	port identifier, or an
	      atom.

       erlang:port_info(Port, Item :: id) -> {id, Index} | undefined

	      Types:

		 Port =	port() | atom()
		 Index = integer() >= 0

	      Index is the internal index of the port. This index can be  used
	      to separate ports.

	      If  the  port  identified	 by Port is not	open, undefined	is re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       erlang:port_info(Port, Item :: input) ->
			   {input, Bytes} | undefined

	      Types:

		 Port =	port() | atom()
		 Bytes = integer() >= 0

	      Bytes is the total number	of bytes read from the port.

	      If  the  port  identified	 by Port is not	open, undefined	is re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       erlang:port_info(Port, Item :: links) ->	{links,	Pids} |	undefined

	      Types:

		 Port =	port() | atom()
		 Pids =	[pid()]

	      Pids  is a list of the process identifiers of the	processes that
	      the port is linked to.

	      If the port identified by	Port is	not  open,  undefined  is  re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure:	badarg	if  Port is not	a local	port identifier, or an
	      atom.

       erlang:port_info(Port, Item :: locking) ->
			   {locking, Locking} |	undefined

	      Types:

		 Port =	port() | atom()
		 Locking = false | port_level |	driver_level

	      Locking is one of	the following:

		* port_level (port-specific locking)

		* driver_level (driver-specific	locking)

	      Notice that these	results	are highly implementation-specific and
	      can change in a future release.

	      If  the  port  identified	 by Port is not	open, undefined	is re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       erlang:port_info(Port, Item :: memory) ->
			   {memory, Bytes} | undefined

	      Types:

		 Port =	port() | atom()
		 Bytes = integer() >= 0

	      Bytes  is	 the  total number of bytes allocated for this port by
	      the runtime system. The port itself can  have  allocated	memory
	      that is not included in Bytes.

	      If  the  port  identified	 by Port is not	open, undefined	is re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       erlang:port_info(Port, Item :: monitors)	->
			   {monitors, Monitors}	| undefined

	      Types:

		 Port =	port() | atom()
		 Monitors = [{process, pid()}]

	      Monitors represent processes monitored by	this port.

	      If  the  port  identified	 by Port is not	open, undefined	is re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       erlang:port_info(Port, Item :: monitored_by) ->
			   {monitored_by, MonitoredBy} | undefined

	      Types:

		 Port =	port() | atom()
		 MonitoredBy = [pid()]

	      Returns  list  of	pids that are monitoring given port at the mo-
	      ment.

	      If the port identified by	Port is	not  open,  undefined  is  re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure:	badarg	if  Port is not	a local	port identifier, or an
	      atom.

       erlang:port_info(Port, Item :: name) -> {name, Name} | undefined

	      Types:

		 Port =	port() | atom()
		 Name =	string()

	      Name is the command name set by open_port/2.

	      If the port identified by	Port is	not  open,  undefined  is  re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure:	badarg	if  Port is not	a local	port identifier, or an
	      atom.

       erlang:port_info(Port, Item :: os_pid) ->
			   {os_pid, OsPid} | undefined

	      Types:

		 Port =	port() | atom()
		 OsPid = integer() >= 0	| undefined

	      OsPid is the process identifier (or equivalent) of an OS process
	      created  with open_port({spawn | spawn_executable, Command}, Op-
	      tions). If the port is not the result of spawning	an OS process,
	      the value	is undefined.

	      If  the  port  identified	 by Port is not	open, undefined	is re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       erlang:port_info(Port, Item :: output) ->
			   {output, Bytes} | undefined

	      Types:

		 Port =	port() | atom()
		 Bytes = integer() >= 0

	      Bytes  is	the total number of bytes written to the port from Er-
	      lang processes using port_command/2, port_command/3, or  Port  !
	      {Owner, {command,	Data}.

	      If  the  port  identified	 by Port is not	open, undefined	is re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       erlang:port_info(Port, Item :: parallelism) ->
			   {parallelism, Boolean} | undefined

	      Types:

		 Port =	port() | atom()
		 Boolean = boolean()

	      Boolean  corresponds  to	the port parallelism hint used by this
	      port.  For  more	information,   see   option   parallelism   of
	      open_port/2.

       erlang:port_info(Port, Item :: queue_size) ->
			   {queue_size,	Bytes} | undefined

	      Types:

		 Port =	port() | atom()
		 Bytes = integer() >= 0

	      Bytes  is	the total number of bytes queued by the	port using the
	      ERTS driver queue	implementation.

	      If the port identified by	Port is	not  open,  undefined  is  re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure:	badarg	if  Port is not	a local	port identifier, or an
	      atom.

       erlang:port_info(Port, Item :: registered_name) ->
			   {registered_name, RegisteredName} |
			   [] |
			   undefined

	      Types:

		 Port =	port() | atom()
		 RegisteredName	= atom()

	      RegisteredName is	the registered name of the port. If  the  port
	      has no registered	name, [] is returned.

	      If  the  port  identified	 by Port is not	open, undefined	is re-
	      turned. If the port is closed and	the calling process was	previ-
	      ously linked to the port,	the exit signal	from the port is guar-
	      anteed to	be delivered before port_info/2	returns	undefined.

	      Failure: badarg if Port is not a local port  identifier,	or  an
	      atom.

       port_to_list(Port) -> string()

	      Types:

		 Port =	port()

	      Returns a	string corresponding to	the text representation	of the
	      port identifier Port.

       erlang:ports() -> [port()]

	      Returns a	list of	port  identifiers  corresponding  to  all  the
	      ports existing on	the local node.

	      Notice that an exiting port exists, but is not open.

       pre_loaded() -> [module()]

	      Returns  a list of Erlang	modules	that are preloaded in the sys-
	      tem. As all loading of code is done through the file system, the
	      file  system  must  have been loaded previously. Hence, at least
	      the module init must be preloaded.

       erlang:process_display(Pid, Type) -> true

	      Types:

		 Pid = pid()
		 Type =	backtrace

	      Writes information about the local process Pid on	 standard  er-
	      ror.  The	 only  allowed	value  for the atom Type is backtrace,
	      which shows the contents of the call stack,  including  informa-
	      tion  about  the	call  chain, with the current function printed
	      first. The format	of the output is not further defined.

       process_flag(Flag :: trap_exit, Boolean)	-> OldBoolean

	      Types:

		 Boolean = OldBoolean =	boolean()

	      When trap_exit is	set  to	 true,	exit  signals  arriving	 to  a
	      process  are converted to	{'EXIT', From, Reason} messages, which
	      can be received as ordinary messages. If	trap_exit  is  set  to
	      false,  the  process  exits  if it receives an exit signal other
	      than normal and the exit signal is propagated to its linked pro-
	      cesses. Application processes are	normally not to	trap exits.

	      Returns the old value of the flag.

	      See also exit/2.

       process_flag(Flag :: error_handler, Module) -> OldModule

	      Types:

		 Module	= OldModule = atom()

	      Used  by	a  process to redefine the error handler for undefined
	      function calls and undefined registered processes. Inexperienced
	      users  are not to	use this flag, as code auto-loading depends on
	      the correct operation of the error handling module.

	      Returns the old value of the flag.

       process_flag(Flag :: min_heap_size, MinHeapSize)	-> OldMinHeapSize

	      Types:

		 MinHeapSize = OldMinHeapSize =	integer() >= 0

	      Changes the minimum heap size for	the calling process.

	      Returns the old value of the flag.

       process_flag(Flag :: min_bin_vheap_size,	MinBinVHeapSize) ->
		       OldMinBinVHeapSize

	      Types:

		 MinBinVHeapSize = OldMinBinVHeapSize =	integer() >= 0

	      Changes the minimum binary virtual heap  size  for  the  calling
	      process.

	      Returns the old value of the flag.

       process_flag(Flag :: max_heap_size, MaxHeapSize)	-> OldMaxHeapSize

	      Types:

		 MaxHeapSize = OldMaxHeapSize =	max_heap_size()
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}

	      This flag	sets the maximum heap size for the calling process. If
	      MaxHeapSize is an	integer, the system default  values  for  kill
	      and error_logger are used.

		size:
		  The  maximum	size  in words of the process. If set to zero,
		  the heap size	limit is disabled. badarg is be	thrown if  the
		  value	 is smaller than min_heap_size.	The size check is only
		  done when a garbage collection is triggered.

		  size is the entire heap of the process when garbage  collec-
		  tion is triggered. This includes all generational heaps, the
		  process stack, any  messages that are	considered to be  part
		  of the heap, and any extra memory that the garbage collector
		  needs	during collection.

		  size	is  the	 same  as   can	  be   retrieved   using   er-
		  lang:process_info(Pid,   total_heap_size),   or   by	adding
		  heap_block_size, old_heap_block_size and mbuf_size from  er-
		  lang:process_info(Pid, garbage_collection_info).

		kill:
		  When	set  to	 true, the runtime system sends	an untrappable
		  exit signal with reason kill to the process if  the  maximum
		  heap	size is	reached. The garbage collection	that triggered
		  the kill is not completed, instead the process exits as soon
		  as  possible.	 When  set to false, no	exit signal is sent to
		  the process, instead it continues executing.

		  If kill is not defined in the	map, the system	 default  will
		  be  used.  The  default  system  default  is true. It	can be
		  changed by either option +hmaxk in  erl(1),  or  erlang:sys-
		  tem_flag(max_heap_size, MaxHeapSize).

		error_logger:
		  When set to true, the	runtime	system logs an error event via
		  logger, containing details about the process when the	 maxi-
		  mum  heap  size  is reached. One log event is	sent each time
		  the limit is reached.

		  If error_logger is not defined in the	map,  the  system  de-
		  fault	is used. The default system default is true. It	can be
		  changed by either the	option	+hmaxel	 int  erl(1),  or  er-
		  lang:system_flag(max_heap_size, MaxHeapSize).

	      The  heap	size of	a process is quite hard	to predict, especially
	      the amount of memory that	is used	during the garbage collection.
	      When contemplating using this option, it is recommended to first
	      run it in	production with	kill set to false and inspect the  log
	      events to	see what the normal peak sizes of the processes	in the
	      system is	and then tune the value	accordingly.

       process_flag(Flag :: message_queue_data,	MQD) ->	OldMQD

	      Types:

		 MQD = OldMQD =	message_queue_data()
		 message_queue_data() =	off_heap | on_heap

	      This flag	determines how	messages  in  the  message  queue  are
	      stored, as follows:

		off_heap:
		  All  messages	in the message queue will be stored outside of
		  the process heap. This implies that no messages in the  mes-
		  sage	queue  will  be	 part  of  a garbage collection	of the
		  process.

		on_heap:
		  All messages in the message queue will eventually be	placed
		  on  heap.  They  can however temporarily be stored off heap.
		  This is how messages always have been	stored up  until  ERTS
		  8.0.

	      The  default  message_queue_data	process	 flag is determined by
	      command-line argument +hmqd in erl(1).

	      If the process potentially can get many messages in  its	queue,
	      you  are	advised	 to  set  the flag to off_heap.	This because a
	      garbage collection with many messages placed on the heap can be-
	      come  extremely  expensive  and  the  process  can consume large
	      amounts of memory. Performance of	the actual message passing  is
	      however generally	better when not	using flag off_heap.

	      When  changing  this  flag messages will be moved. This work has
	      been initiated but not completed when  this  function  call  re-
	      turns.

	      Returns the old value of the flag.

       process_flag(Flag :: priority, Level) ->	OldLevel

	      Types:

		 Level = OldLevel = priority_level()
		 priority_level() = low	| normal | high	| max

	      Sets  the	process	priority. Level	is an atom. Four priority lev-
	      els exist: low, normal, high, and	max. Default is	normal.

	  Note:
	      Priority level max is reserved for internal use  in  the	Erlang
	      runtime system, and is not to be used by others.

	      Internally  in each priority level, processes are	scheduled in a
	      round robin fashion.

	      Execution	of processes on	priority normal	 and  low  are	inter-
	      leaved.  Processes  on  priority	low are	selected for execution
	      less frequently than processes on	priority normal.

	      When runnable processes on priority high exist, no processes  on
	      priority	low  or	normal are selected for	execution. Notice how-
	      ever that	this does not mean that	no processes on	 priority  low
	      or  normal  can run when processes are running on	priority high.
	      When using multiple schedulers, more processes can be running in
	      parallel	than  processes	on priority high. That is, a low and a
	      high priority process can	execute	at the same time.

	      When runnable processes on priority max exist, no	 processes  on
	      priority	low,  normal,  or  high	are selected for execution. As
	      with priority high, processes on lower priorities	can execute in
	      parallel with processes on priority max.

	      Scheduling  is pre-emptive. Regardless of	priority, a process is
	      pre-empted when it has consumed more than	a  certain  number  of
	      reductions since the last	time it	was selected for execution.

	  Note:
	      Do  not  depend on the scheduling	to remain exactly as it	is to-
	      day. Scheduling is likely	to be changed in a future  release  to
	      use available processor cores better.

	      There is no automatic mechanism for avoiding priority inversion,
	      such as priority inheritance or priority	ceilings.  When	 using
	      priorities,  take	this into account and handle such scenarios by
	      yourself.

	      Making calls from	a high priority	process	into code that you has
	      no  control over can cause the high priority process to wait for
	      a	process	with lower priority. That is,  effectively  decreasing
	      the  priority of the high	priority process during	the call. Even
	      if this is not the case with one version of the  code  that  you
	      have  no control over, it	can be the case	in a future version of
	      it. This can, for	example, occur	if  a  high  priority  process
	      triggers	code loading, as the code server runs on priority nor-
	      mal.

	      Other priorities than normal are normally	not needed. When other
	      priorities  are  used,  use  them	with care, especially priority
	      high. A process on priority high is only	to  perform  work  for
	      short  periods. Busy looping for long periods in a high priority
	      process causes most likely problems, as  important  OTP  servers
	      run on priority normal.

	      Returns the old value of the flag.

       process_flag(Flag :: save_calls,	N) -> OldN

	      Types:

		 N = OldN = 0..10000

	      N	 must  be  an integer in the interval 0..10000.	If N > 0, call
	      saving is	made active for	the process. This means	that  informa-
	      tion  about  the N most recent global function calls, BIF	calls,
	      sends, and receives made by the process are  saved  in  a	 list,
	      which  can  be  retrieved	 with process_info(Pid,	last_calls). A
	      global function call is one in which the module of the  function
	      is  explicitly  mentioned. Only a	fixed amount of	information is
	      saved, as	follows:

		* A tuple {Module, Function, Arity} for	function calls

		* The atoms send, 'receive', and timeout  for  sends  and  re-
		  ceives  ('receive'  when  a  message is received and timeout
		  when a receive times out)

	      If N = 0,	call saving is disabled	for the	process, which is  the
	      default.	Whenever  the size of the call saving list is set, its
	      contents are reset.

	      Returns the old value of the flag.

       process_flag(Flag :: sensitive, Boolean)	-> OldBoolean

	      Types:

		 Boolean = OldBoolean =	boolean()

	      Sets or clears flag sensitive for	the current  process.  When  a
	      process	 has	been	marked	 as   sensitive	  by   calling
	      process_flag(sensitive, true), features in  the  runtime	system
	      that  can	be used	for examining the data or inner	working	of the
	      process are silently disabled.

	      Features that are	disabled include (but are not limited to)  the
	      following:

		* Tracing.  Trace  flags can still be set for the process, but
		  no trace messages of any kind	are generated. (If flag	sensi-
		  tive	is  turned  off, trace messages	are again generated if
		  any trace flags are set.)

		* Sequential tracing. The sequential trace token is propagated
		  as usual, but	no sequential trace messages are generated.

	      process_info/1,2 cannot be used to read out the message queue or
	      the process dictionary (both are returned	as empty lists).

	      Stack back-traces	cannot be displayed for	the process.

	      In crash dumps, the stack, messages, and the process  dictionary
	      are omitted.

	      If  {save_calls,N}  has  been  set  for the process, no function
	      calls are	saved to the call saving list. (The call  saving  list
	      is  not  cleared.	 Also,	send, receive, and time-out events are
	      still added to the list.)

	      Returns the old value of the flag.

       process_flag(Pid, Flag, Value) -> OldValue

	      Types:

		 Pid = pid()
		 Flag =	save_calls
		 Value = OldValue = integer() >= 0

	      Sets certain flags for the process Pid, in the  same  manner  as
	      process_flag/2.  Returns	the  old  value	of the flag. The valid
	      values  for  Flag	 are  only  a  subset  of  those  allowed   in
	      process_flag/2, namely save_calls.

	      Failure: badarg if Pid is	not a local process.

       process_info(Pid) -> Info

	      Types:

		 Pid = pid()
		 Info =	[InfoTuple] | undefined
		 InfoTuple = process_info_result_item()
		 process_info_result_item() =
		     {backtrace, Bin ::	binary()} |
		     {binary,
		      BinInfo ::
			  [{integer() >= 0,
			    integer() >= 0,
			    integer() >= 0}]} |
		     {catchlevel, CatchLevel ::	integer() >= 0}	|
		     {current_function,
		      {Module :: module(), Function :: atom(), Arity ::	arity()}} |
		     {current_location,
		      {Module :: module(),
		       Function	:: atom(),
		       Arity ::	arity(),
		       Location	::
			   [{file, Filename :: string()} |
			    {line, Line	:: integer() >=	1}]}} |
		     {current_stacktrace, Stack	:: [stack_item()]} |
		     {dictionary, Dictionary ::	[{Key :: term(), Value :: term()}]} |
		     {error_handler, Module :: module()} |
		     {garbage_collection, GCInfo :: [{atom(), integer()	>= 0}]}	|
		     {garbage_collection_info,
		      GCInfo ::	[{atom(), integer() >= 0}]} |
		     {group_leader, GroupLeader	:: pid()} |
		     {heap_size, Size :: integer() >= 0} |
		     {initial_call, mfa()} |
		     {links, PidsAndPorts :: [pid() | port()]} |
		     {last_calls, false	| (Calls :: [mfa()])} |
		     {memory, Size :: integer()	>= 0} |
		     {message_queue_len, MessageQueueLen :: integer() >= 0} |
		     {messages,	MessageQueue ::	[term()]} |
		     {min_heap_size, MinHeapSize :: integer() >= 0} |
		     {min_bin_vheap_size, MinBinVHeapSize :: integer() >= 0} |
		     {max_heap_size, MaxHeapSize :: max_heap_size()} |
		     {monitored_by,
		      MonitoredBy :: [pid() | port() | nif_resource()]}	|
		     {monitors,
		      Monitors ::
			  [{process | port,
			    Pid	::
				pid() |
				port() |
				{RegName :: atom(), Node :: node()}}]} |
		     {message_queue_data, MQD :: message_queue_data()} |
		     {priority,	Level :: priority_level()} |
		     {reductions, Number :: integer() >= 0} |
		     {registered_name, [] | (Atom :: atom())} |
		     {sequential_trace_token,
		      [] | (SequentialTraceToken :: term())} |
		     {stack_size, Size :: integer() >= 0} |
		     {status,
		      Status ::
			  exiting |
			  garbage_collecting |
			  waiting |
			  running |
			  runnable |
			  suspended} |
		     {suspending,
		      SuspendeeList ::
			  [{Suspendee :: pid(),
			    ActiveSuspendCount :: integer() >= 0,
			    OutstandingSuspendCount :: integer() >= 0}]} |
		     {total_heap_size, Size :: integer() >= 0} |
		     {trace, InternalTraceFlags	:: integer() >=	0} |
		     {trap_exit, Boolean :: boolean()}
		 priority_level() = low	| normal | high	| max
		 stack_item() =
		     {Module ::	module(),
		      Function :: atom(),
		      Arity :: arity() | (Args :: [term()]),
		      Location ::
			  [{file, Filename :: string()}	|
			   {line, Line :: integer() >= 1}]}
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}
		 message_queue_data() =	off_heap | on_heap

	      Returns a	list containing	InfoTuples with	miscellaneous informa-
	      tion about the process identified	by Pid,	or  undefined  if  the
	      process is not alive.

	      The  order of the	InfoTuples is undefined	and all	InfoTuples are
	      not mandatory. The InfoTuples part of the	result can be  changed
	      without prior notice.

	      The InfoTuples with the following	items are part of the result:

		* current_function

		* initial_call

		* status

		* message_queue_len

		* links

		* dictionary

		* trap_exit

		* error_handler

		* priority

		* group_leader

		* total_heap_size

		* heap_size

		* stack_size

		* reductions

		* garbage_collection

	      If  the process identified by Pid	has a registered name, also an
	      InfoTuple	with item registered_name is included.

	      For information about specific InfoTuples, see process_info/2.

	  Warning:
	      This BIF is intended for debugging only. For all other purposes,
	      use process_info/2.

	      Failure: badarg if Pid is	not a local process.

       process_info(Pid, Item) -> InfoTuple | [] | undefined

       process_info(Pid, ItemList) -> InfoTupleList | [] | undefined

	      Types:

		 Pid = pid()
		 ItemList = [Item]
		 Item =	process_info_item()
		 InfoTupleList = [InfoTuple]
		 InfoTuple = process_info_result_item()
		 process_info_item() =
		     backtrace |
		     binary |
		     catchlevel	|
		     current_function |
		     current_location |
		     current_stacktrace	|
		     dictionary	|
		     error_handler |
		     garbage_collection	|
		     garbage_collection_info |
		     group_leader |
		     heap_size |
		     initial_call |
		     links |
		     last_calls	|
		     memory |
		     message_queue_len |
		     messages |
		     min_heap_size |
		     min_bin_vheap_size	|
		     monitored_by |
		     monitors |
		     message_queue_data	|
		     priority |
		     reductions	|
		     registered_name |
		     sequential_trace_token |
		     stack_size	|
		     status |
		     suspending	|
		     total_heap_size |
		     trace |
		     trap_exit
		 process_info_result_item() =
		     {backtrace, Bin ::	binary()} |
		     {binary,
		      BinInfo ::
			  [{integer() >= 0,
			    integer() >= 0,
			    integer() >= 0}]} |
		     {catchlevel, CatchLevel ::	integer() >= 0}	|
		     {current_function,
		      {Module :: module(), Function :: atom(), Arity ::	arity()}} |
		     {current_location,
		      {Module :: module(),
		       Function	:: atom(),
		       Arity ::	arity(),
		       Location	::
			   [{file, Filename :: string()} |
			    {line, Line	:: integer() >=	1}]}} |
		     {current_stacktrace, Stack	:: [stack_item()]} |
		     {dictionary, Dictionary ::	[{Key :: term(), Value :: term()}]} |
		     {error_handler, Module :: module()} |
		     {garbage_collection, GCInfo :: [{atom(), integer()	>= 0}]}	|
		     {garbage_collection_info,
		      GCInfo ::	[{atom(), integer() >= 0}]} |
		     {group_leader, GroupLeader	:: pid()} |
		     {heap_size, Size :: integer() >= 0} |
		     {initial_call, mfa()} |
		     {links, PidsAndPorts :: [pid() | port()]} |
		     {last_calls, false	| (Calls :: [mfa()])} |
		     {memory, Size :: integer()	>= 0} |
		     {message_queue_len, MessageQueueLen :: integer() >= 0} |
		     {messages,	MessageQueue ::	[term()]} |
		     {min_heap_size, MinHeapSize :: integer() >= 0} |
		     {min_bin_vheap_size, MinBinVHeapSize :: integer() >= 0} |
		     {max_heap_size, MaxHeapSize :: max_heap_size()} |
		     {monitored_by,
		      MonitoredBy :: [pid() | port() | nif_resource()]}	|
		     {monitors,
		      Monitors ::
			  [{process | port,
			    Pid	::
				pid() |
				port() |
				{RegName :: atom(), Node :: node()}}]} |
		     {message_queue_data, MQD :: message_queue_data()} |
		     {priority,	Level :: priority_level()} |
		     {reductions, Number :: integer() >= 0} |
		     {registered_name, [] | (Atom :: atom())} |
		     {sequential_trace_token,
		      [] | (SequentialTraceToken :: term())} |
		     {stack_size, Size :: integer() >= 0} |
		     {status,
		      Status ::
			  exiting |
			  garbage_collecting |
			  waiting |
			  running |
			  runnable |
			  suspended} |
		     {suspending,
		      SuspendeeList ::
			  [{Suspendee :: pid(),
			    ActiveSuspendCount :: integer() >= 0,
			    OutstandingSuspendCount :: integer() >= 0}]} |
		     {total_heap_size, Size :: integer() >= 0} |
		     {trace, InternalTraceFlags	:: integer() >=	0} |
		     {trap_exit, Boolean :: boolean()}
		 stack_item() =
		     {Module ::	module(),
		      Function :: atom(),
		      Arity :: arity() | (Args :: [term()]),
		      Location ::
			  [{file, Filename :: string()}	|
			   {line, Line :: integer() >= 1}]}
		 priority_level() = low	| normal | high	| max
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}
		 message_queue_data() =	off_heap | on_heap

	      Returns  information  about  the	process	 identified by Pid, as
	      specified	by Item	or ItemList. Returns undefined if the  process
	      is not alive.

	      If  the process is alive and a single Item is specified, the re-
	      turned value is the corresponding	 InfoTuple,  unless  Item  =:=
	      registered_name  and the process has no registered name. In this
	      case, [] is returned. This strange behavior is because  of  his-
	      torical reasons, and is kept for backward	compatibility.

	      If ItemList is specified,	the result is InfoTupleList. The Info-
	      Tuples in	InfoTupleList  are  included  with  the	 corresponding
	      Items  in	the same order as the Items were included in ItemList.
	      Valid Items can be included multiple times in ItemList.

	  Note:
	      If registered_name is part of ItemList and the  process  has  no
	      name  registered,	a {registered_name, []}, InfoTuple will	be in-
	      cluded in	the resulting InfoTupleList. This behavior is  differ-
	      ent  when	 a  single  Item =:= registered_name is	specified, and
	      when process_info/1 is used.

	      Valid InfoTuples with corresponding Items:

		{backtrace, Bin}:
		  Binary Bin contains the same information as the output  from
		  erlang:process_display(Pid, backtrace). Use binary_to_list/1
		  to obtain the	string of characters from the binary.

		{binary, BinInfo}:
		  BinInfo is a list containing miscellaneous information about
		  binaries  on the heap	of this	process. This InfoTuple	can be
		  changed or removed without prior notice. In the current  im-
		  plementation	BinInfo	 is  a list of tuples. The tuples con-
		  tain;	BinaryId, BinarySize, BinaryRefcCount.

		  The message queue is on the heap depending  on  the  process
		  flag message_queue_data.

		{catchlevel, CatchLevel}:
		  CatchLevel is	the number of currently	active catches in this
		  process. This	InfoTuple can be changed  or  removed  without
		  prior	notice.

		{current_function, {Module, Function, Arity}}:
		  Module,  Function, Arity is the current function call	of the
		  process.

		{current_location, {Module, Function, Arity, Location}}:
		  Module, Function, Arity is the current function call of  the
		  process. Location is a list of two-tuples describing the lo-
		  cation in the	source code.

		{current_stacktrace, Stack}:
		  Returns the current call stack  back-trace  (stacktrace)  of
		  the  process.	 The  stack has	the same format	as returned by
		  erlang:get_stacktrace/0. The	depth  of  the	stacktrace  is
		  truncated  according to the backtrace_depth system flag set-
		  ting.

		{dictionary, Dictionary}:
		  Dictionary is	the process dictionary.

		{error_handler,	Module}:
		  Module is the	error handler module used by the process  (for
		  undefined function calls, for	example).

		{garbage_collection, GCInfo}:
		  GCInfo  is a list containing miscellaneous information about
		  garbage collection for this process. The content  of	GCInfo
		  can be changed without prior notice.

		{garbage_collection_info, GCInfo}:
		  GCInfo  is a list containing miscellaneous detailed informa-
		  tion about garbage collection	for this process. The  content
		  of  GCInfo  can be changed without prior notice. For details
		  about	the meaning of each item, see  gc_minor_start  in  er-
		  lang:trace/3.

		{group_leader, GroupLeader}:
		  GroupLeader is the group leader for the I/O of the process.

		{heap_size, Size}:
		  Size is the size in words of the youngest heap generation of
		  the process. This generation	includes  the  process	stack.
		  This information is highly implementation-dependent, and can
		  change if the	implementation changes.

		{initial_call, {Module,	Function, Arity}}:
		  Module, Function, Arity is the initial  function  call  with
		  which	the process was	spawned.

		{links,	PidsAndPorts}:
		  PidsAndPorts is a list of process identifiers	and port iden-
		  tifiers, with	processes or ports to which the	process	has  a
		  link.

		{last_calls, false|Calls}:
		  The  value  is  false	 if  call saving is not	active for the
		  process (see process_flag/3).	If call	saving	is  active,  a
		  list	is returned, in	which the last element is the most re-
		  cent called.

		{memory, Size}:
		  Size is the size in bytes of the process. This includes call
		  stack, heap, and internal structures.

		{message_queue_len, MessageQueueLen}:
		  MessageQueueLen  is  the number of messages currently	in the
		  message queue	of the process.	This is	the length of the list
		  MessageQueue	returned as the	information item messages (see
		  below).

		{messages, MessageQueue}:
		  MessageQueue is a list of the	messages to the	process, which
		  have not yet been processed.

		{min_heap_size,	MinHeapSize}:
		  MinHeapSize is the minimum heap size for the process.

		{min_bin_vheap_size, MinBinVHeapSize}:
		  MinBinVHeapSize  is the minimum binary virtual heap size for
		  the process.

		{monitored_by, MonitoredBy}:
		  A list of identifiers	for all	the processes, ports  and  NIF
		  resources, that are monitoring the process.

		{monitors, Monitors}:
		  A  list  of  monitors	(started by monitor/2) that are	active
		  for the process. For a local process	monitor	 or  a	remote
		  process  monitor  by a process identifier, the list consists
		  of:

		  {process, Pid}:
		    Process is monitored by pid.

		  {process, {RegName, Node}}:
		    Local or remote process is monitored by name.

		  {port, PortId}:
		    Local port is monitored by port id.

		  {port, {RegName, Node}}:
		    Local port is monitored by name. Please note, that	remote
		    port  monitors  are	 not supported,	so Node	will always be
		    the	local node name.

		{message_queue_data, MQD}:
		  Returns   the	  current   state   of	 process   flag	  mes-
		  sage_queue_data. MQD is either off_heap or on_heap. For more
		  information,	see  the  documentation	 of  process_flag(mes-
		  sage_queue_data, MQD).

		{priority, Level}:
		  Level	 is  the  current  priority level for the process. For
		  more information on priorities,  see	process_flag(priority,
		  Level).

		{reductions, Number}:
		  Number is the	number of reductions executed by the process.

		{registered_name, Atom}:
		  Atom	is  the	registered process name. If the	process	has no
		  registered name, this	tuple is not present in	the list.

		{sequential_trace_token, [] | SequentialTraceToken}:
		  SequentialTraceToken is the sequential trace token  for  the
		  process.  This  InfoTuple  can be changed or removed without
		  prior	notice.

		{stack_size, Size}:
		  Size is the stack size, in words, of the process.

		{status, Status}:
		  Status is the	status of the process and is one of  the  fol-
		  lowing:

		  * exiting

		  * garbage_collecting

		  * waiting (for a message)

		  * running

		  * runnable (ready to run, but	another	process	is running)

		  * suspended  (suspended  on  a "busy"	port or	by the BIF er-
		    lang:suspend_process/1,2)

		{suspending, SuspendeeList}:
		  SuspendeeList	is a list of  {Suspendee,  ActiveSuspendCount,
		  OutstandingSuspendCount}  tuples.  Suspendee	is the process
		  identifier of	a process that has been, or  is	 to  be,  sus-
		  pended  by the process identified by Pid through the BIF er-
		  lang:suspend_process/2 or erlang:suspend_process/1.

		  ActiveSuspendCount is	the number of times Suspendee has been
		  suspended  by	 Pid. OutstandingSuspendCount is the number of
		  not yet completed suspend requests sent by Pid, that is:

		  * If ActiveSuspendCount =/= 0, Suspendee is currently	in the
		    suspended state.

		  * If	OutstandingSuspendCount	 =/= 0,	option asynchronous of
		    erlang:suspend_process/2 has been used and	the  suspendee
		    has	not yet	been suspended by Pid.

		  Notice  that	ActiveSuspendCount and OutstandingSuspendCount
		  are not the total suspend count on Suspendee,	only the parts
		  contributed by Pid.

		{total_heap_size, Size}:
		  Size	is  the	total size, in words, of all heap fragments of
		  the process. This includes the process stack and  any	 unre-
		  ceived messages that are considered to be part of the	heap.

		{trace,	InternalTraceFlags}:
		  InternalTraceFlags  is  an integer representing the internal
		  trace	flag for this process. This InfoTuple can  be  changed
		  or removed without prior notice.

		{trap_exit, Boolean}:
		  Boolean  is true if the process is trapping exits, otherwise
		  false.

	      Notice that not all implementations support all these Items.

	      Failures:

		badarg:
		  If Pid is not	a local	process.

		badarg:
		  If Item is an	invalid	item.

       processes() -> [pid()]

	      Returns a	list of	process	identifiers corresponding to  all  the
	      processes	currently existing on the local	node.

	      Notice  that  an	exiting	process	exists,	but is not alive. That
	      is, is_process_alive/1 returns false for an exiting process, but
	      its  process identifier is part of the result returned from pro-
	      cesses/0.

	      Example:

	      >	processes().
	      [<0.0.0>,<0.2.0>,<0.4.0>,<0.5.0>,<0.7.0>,<0.8.0>]

       purge_module(Module) -> true

	      Types:

		 Module	= atom()

	      Removes  old  code  for  Module.	Before	this  BIF   is	 used,
	      check_process_code/2is  to  be called to check that no processes
	      execute old code in the module.

	  Warning:
	      This BIF is intended for the code	server (see  code(3))  and  is
	      not to be	used elsewhere.

	  Note:
	      As  from	ERTS 8.0 (Erlang/OTP 19), any lingering	processes that
	      still execute the	old code is killed by this function.  In  ear-
	      lier  versions,  such  incorrect use could cause much more fatal
	      failures,	like emulator crash.

	      Failure: badarg if there is no old code for Module.

       put(Key,	Val) ->	term()

	      Types:

		 Key = Val = term()

	      Adds a new Key to	the process dictionary,	 associated  with  the
	      value  Val,  and returns undefined. If Key exists, the old value
	      is deleted and replaced by Val, and the function returns the old
	      value. Example:

	      >	X = put(name, walrus), Y = put(name, carpenter),
	      Z	= get(name),
	      {X, Y, Z}.
	      {undefined,walrus,carpenter}

	  Note:
	      The  values  stored  when	put is evaluated within	the scope of a
	      catch are	not retracted if a throw is evaluated, or if an	 error
	      occurs.

       erlang:raise(Class, Reason, Stacktrace) -> no_return()

	      Types:

		 Class = error | exit |	throw
		 Reason	= term()
		 Stacktrace = raise_stacktrace()
		 raise_stacktrace() =
		     [{module(), atom(), arity() | [term()]} |
		      {function(), [term()]}] |
		     [{module(), atom(), arity() | [term()], [{atom(), term()}]} |
		      {function(), [term()], [{atom(), term()}]}]

	      Stops  the execution of the calling process with an exception of
	      the specified class, reason, and call  stack  backtrace  (stack-
	      trace).

	      Class  is	 error,	 exit,	or  throw.  So,	if it were not for the
	      stacktrace, erlang:raise(Class, Reason, Stacktrace)  is  equiva-
	      lent to erlang:Class(Reason).

	      Reason  is  any  term.  Stacktrace  is  a	 list as returned from
	      get_stacktrace(),	that is, a list	of four-tuples {Module,	 Func-
	      tion,  Arity  |  Args,  Location}, where Module and Function are
	      atoms, and the third element is an integer arity or an  argument
	      list.  The stacktrace can	also contain {Fun, Args, Location} tu-
	      ples, where Fun is a local fun and Args is an argument list.

	      Element Location at the end is optional. Omitting	it is  equiva-
	      lent to specifying an empty list.

	      The stacktrace is	used as	the exception stacktrace for the call-
	      ing process; it is truncated to the current  maximum  stacktrace
	      depth.

	      As  evaluating this function causes the process to terminate, it
	      has no return value unless the arguments are invalid,  in	 which
	      case  the	 function returns the error reason badarg. If you want
	      to be sure not to	return,	you can	call error(erlang:raise(Class,
	      Reason, Stacktrace)) and hope to distinguish exceptions later.

       erlang:read_timer(TimerRef) -> Result

	      Types:

		 TimerRef = reference()
		 Time =	integer() >= 0
		 Result	= Time | false

	      Reads   the   state   of	a  timer.  The	same  as  calling  er-
	      lang:read_timer(TimerRef,	[]).

       erlang:read_timer(TimerRef, Options) -> Result |	ok

	      Types:

		 TimerRef = reference()
		 Async = boolean()
		 Option	= {async, Async}
		 Options = [Option]
		 Time =	integer() >= 0
		 Result	= Time | false

	      Reads the	state of a timer that has been created by  either  er-
	      lang:start_timer	or  erlang:send_after. TimerRef	identifies the
	      timer, and was returned by the BIF that created the timer.

	      Options:

		{async,	Async}:
		  Asynchronous request for state information.  Async  defaults
		  to  false,  which  causes the	operation to be	performed syn-
		  chronously. In this case, the	 Result	 is  returned  by  er-
		  lang:read_timer. When	Async is true, erlang:read_timer sends
		  an asynchronous request for the  state  information  to  the
		  timer	service	that manages the timer,	and then returns ok. A
		  message on the format	{read_timer, TimerRef, Result} is sent
		  to  the  caller  of erlang:read_timer	when the operation has
		  been processed.

	      More Options can be added	in the future.

	      If Result	is an integer, it represents the time in  milliseconds
	      left until the timer expires.

	      If  Result is false, a timer corresponding to TimerRef could not
	      be found.	This because the timer had expired, or been  canceled,
	      or  because  TimerRef never has corresponded to a	timer. Even if
	      the timer	has expired, it	does not tell you whether or  not  the
	      time-out message has arrived at its destination yet.

	  Note:
	      The  timer service that manages the timer	can be co-located with
	      another scheduler	than the scheduler that	the calling process is
	      executing	 on. If	so, communication with the timer service takes
	      much longer time than if it is located locally. If  the  calling
	      process  is  in  a  critical path, and can do other things while
	      waiting for the result of	this operation,	you want to use	option
	      {async,  true}.  If  using  option  {async,  false}, the calling
	      process is blocked until the operation has been performed.

	      See  also	 erlang:send_after/4,  erlang:start_timer/4,  and  er-
	      lang:cancel_timer/2.

       ref_to_list(Ref)	-> string()

	      Types:

		 Ref = reference()

	      Returns  a  string  corresponding	 to the	text representation of
	      Ref.

	  Warning:
	      This BIF is intended for debugging and is	not to be used in  ap-
	      plication	programs.

       register(RegName, PidOrPort) -> true

	      Types:

		 RegName = atom()
		 PidOrPort = port() | pid()

	      Associates the name RegName with a process identifier (pid) or a
	      port identifier. RegName,	which must be an atom, can be used in-
	      stead  of	the pid	or port	identifier in send operator (RegName !
	      Message).	Example:

	      >	register(db, Pid).
	      true

	      Failures:

		badarg:
		  If PidOrPort is not an existing local	process	or port.

		badarg:
		  If RegName is	already	in use.

		badarg:
		  If the process or port is already registered (already	has  a
		  name).

		badarg:
		  If RegName is	the atom undefined.

       registered() -> [RegName]

	      Types:

		 RegName = atom()

	      Returns  a  list of names	that have been registered using	regis-
	      ter/2, for example:

	      >	registered().
	      [code_server, file_server, init, user, my_db]

       erlang:resume_process(Suspendee)	-> true

	      Types:

		 Suspendee = pid()

	      Decreases	the suspend count on the process  identified  by  Sus-
	      pendee.  Suspendee  is previously	to have	been suspended through
	      erlang:suspend_process/2	or  erlang:suspend_process/1  by   the
	      process  calling erlang:resume_process(Suspendee). When the sus-
	      pend count on Suspendee reaches zero, Suspendee is resumed, that
	      is,  its	state  is changed from suspended into the state	it had
	      before it	was suspended.

	  Warning:
	      This BIF is intended for debugging only.

	      Failures:

		badarg:
		   If Suspendee	is not a process identifier.

		badarg:
		   If the process calling erlang:resume_process/1 had not pre-
		  viously  increased  the suspend count	on the process identi-
		  fied by Suspendee.

		badarg:
		   If the process identified by	Suspendee is not alive.

       round(Number) ->	integer()

	      Types:

		 Number	= number()

	      Returns an integer by rounding Number, for example:

	      round(5.5).
	      6

	      Allowed in guard tests.

       self() -> pid()

	      Returns the process identifier of	the calling process, for exam-
	      ple:

	      >	self().
	      <0.26.0>

	      Allowed in guard tests.

       erlang:send(Dest, Msg) -> Msg

	      Types:

		 Dest =	dst()
		 Msg = term()
		 dst() =
		     pid() |
		     port() |
		     (RegName :: atom()) |
		     {RegName :: atom(), Node :: node()}

	      Sends  a	message	and returns Msg. This is the same as using the
	      send operator: Dest ! Msg.

	      Dest can be a remote or  local  process  identifier,  a  (local)
	      port,  a locally registered name,	or a tuple {RegName, Node} for
	      a	registered name	at another node.

	      The function fails with a	badarg run-time	error if  Dest	is  an
	      atom  name,  but	this  name is not registered. This is the only
	      case when	send fails for an  unreachable	destination  Dest  (of
	      correct type).

       erlang:send(Dest, Msg, Options) -> Res

	      Types:

		 Dest =	dst()
		 Msg = term()
		 Options = [nosuspend |	noconnect]
		 Res = ok | nosuspend |	noconnect
		 dst() =
		     pid() |
		     port() |
		     (RegName :: atom()) |
		     {RegName :: atom(), Node :: node()}

	      Either sends a message and returns ok, or	does not send the mes-
	      sage but returns something else (see below). Otherwise the  same
	      as  erlang:send/2.  For  more detailed explanation and warnings,
	      see erlang:send_nosuspend/2,3.

	      Options:

		nosuspend:
		  If the sender	would have to be suspended to do the send, no-
		  suspend is returned instead.

		noconnect:
		   If  the destination node would have to be auto-connected to
		  do the send, noconnect is returned instead.

	  Warning:
	      As with erlang:send_nosuspend/2,3: use with extreme care.

       erlang:send_after(Time, Dest, Msg) -> TimerRef

	      Types:

		 Time =	integer() >= 0
		 Dest =	pid() |	atom()
		 Msg = term()
		 TimerRef = reference()

	      Starts a timer.  The  same  as  calling  erlang:send_after(Time,
	      Dest, Msg, []).

       erlang:send_after(Time, Dest, Msg, Options) -> TimerRef

	      Types:

		 Time =	integer()
		 Dest =	pid() |	atom()
		 Msg = term()
		 Options = [Option]
		 Abs = boolean()
		 Option	= {abs,	Abs}
		 TimerRef = reference()

	      Starts  a	timer. When the	timer expires, the message Msg is sent
	      to the process identified	by Dest. Apart from the	format of  the
	      time-out	 message,   this   function   works   exactly  as  er-
	      lang:start_timer/4.

       erlang:send_nosuspend(Dest, Msg)	-> boolean()

	      Types:

		 Dest =	dst()
		 Msg = term()
		 dst() =
		     pid() |
		     port() |
		     (RegName :: atom()) |
		     {RegName :: atom(), Node :: node()}

	      The same as erlang:send(Dest,  Msg,  [nosuspend]),  but  returns
	      true  if	the  message was sent and false	if the message was not
	      sent because the sender would have had to	be suspended.

	      This function is intended	for send operations to	an  unreliable
	      remote  node without ever	blocking the sending (Erlang) process.
	      If the connection	to the remote node (usually not	a real	Erlang
	      node, but	a node written in C or Java) is	overloaded, this func-
	      tion does	not send the message and returns false.

	      The same occurs if Dest refers to	a local	port that is busy. For
	      all  other  destinations (allowed	for the	ordinary send operator
	      '!'), this function sends	the message and	returns	true.

	      This function is only to be used in rare circumstances  where  a
	      process  communicates with Erlang	nodes that can disappear with-
	      out any trace, causing the TCP buffers and the drivers queue  to
	      be over-full before the node is shut down	(because of tick time-
	      outs) by net_kernel. The normal reaction to take when  this  oc-
	      curs is some kind	of premature shutdown of the other node.

	      Notice  that  ignoring the return	value from this	function would
	      result in	an unreliable message passing, which is	 contradictory
	      to the Erlang programming	model. The message is not sent if this
	      function returns false.

	      In many systems, transient states	of overloaded queues are  nor-
	      mal. Although this function returns false	does not mean that the
	      other node is guaranteed to be non-responsive,  it  could	 be  a
	      temporary	 overload. Also, a return value	of true	does only mean
	      that the message can be sent on the (TCP)	channel	without	block-
	      ing; the message is not guaranteed to arrive at the remote node.
	      For a disconnected non-responsive	node, the return value is true
	      (mimics  the  behavior of	operator !). The expected behavior and
	      the actions to take when the function returns false are applica-
	      tion- and	hardware-specific.

	  Warning:
	      Use with extreme care.

       erlang:send_nosuspend(Dest, Msg,	Options) -> boolean()

	      Types:

		 Dest =	dst()
		 Msg = term()
		 Options = [noconnect]
		 dst() =
		     pid() |
		     port() |
		     (RegName :: atom()) |
		     {RegName :: atom(), Node :: node()}

	      The  same	 as erlang:send(Dest, Msg, [nosuspend |	Options]), but
	      with a Boolean return value.

	      This function behaves like erlang:send_nosuspend/2, but takes  a
	      third  parameter,	 a  list of options. The only option is	nocon-
	      nect, which makes	the function return false if the  remote  node
	      is  not currently	reachable by the local node. The normal	behav-
	      ior is to	try to connect	to  the	 node,	which  can  stall  the
	      process during a short period. The use of	option noconnect makes
	      it possible to be	sure not to get	the slightest delay when send-
	      ing to a remote process. This is especially useful when communi-
	      cating with nodes	that expect to always be the  connecting  part
	      (that is,	nodes written in C or Java).

	      Whenever the function returns false (either when a suspend would
	      occur or when noconnect was specified and	the node was  not  al-
	      ready  connected),  the  message	is guaranteed not to have been
	      sent.

	  Warning:
	      Use with extreme care.

       erlang:set_cookie(Node, Cookie) -> true

	      Types:

		 Node =	node()
		 Cookie	= atom()

	      Sets the magic cookie of Node to the atom	Cookie.	If Node	is the
	      local  node,  the	function also sets the cookie of all other un-
	      known nodes to Cookie (see section  Distributed  Erlang  in  the
	      Erlang Reference Manual in System	Documentation).

	      Failure: function_clause if the local node is not	alive.

       setelement(Index, Tuple1, Value)	-> Tuple2

	      Types:

		 Index = integer() >= 1
		   1..tuple_size(Tuple1
		 Tuple1	= Tuple2 = tuple()
		 Value = term()

	      Returns  a tuple that is a copy of argument Tuple1 with the ele-
	      ment specified by	integer	argument Index (the first  element  is
	      the  element with	index 1) replaced by argument Value, for exam-
	      ple:

	      >	setelement(2, {10, green, bottles}, red).
	      {10,red,bottles}

       size(Item) -> integer() >= 0

	      Types:

		 Item =	tuple()	| binary()

	      Returns the number of elements in	a tuple	or the number of bytes
	      in a binary or bitstring,	for example:

	      >	size({morni, mulle, bwange}).
	      3
	      >	size(<<11, 22, 33>>).
	      3

	      For  bitstrings, the number of whole bytes is returned. That is,
	      if the number of bits in the bitstring is	not  divisible	by  8,
	      the resulting number of bytes is rounded down.

	      Allowed in guard tests.

	      See also tuple_size/1, byte_size/1, and bit_size/1.

       spawn(Fun) -> pid()

	      Types:

		 Fun = function()

	      Returns  the  process identifier of a new	process	started	by the
	      application of Fun to the	empty list [].	Otherwise  works  like
	      spawn/3.

       spawn(Node, Fun)	-> pid()

	      Types:

		 Node =	node()
		 Fun = function()

	      Returns  the  process identifier of a new	process	started	by the
	      application of Fun to the	empty list [] on Node.	If  Node  does
	      not  exist,  a  useless  pid  is	returned. Otherwise works like
	      spawn/3.

       spawn(Module, Function, Args) ->	pid()

	      Types:

		 Module	= module()
		 Function = atom()
		 Args =	[term()]

	      Returns the process identifier of	a new process started  by  the
	      application of Module:Function to	Args.

	      error_handler:undefined_function(Module,	 Function,   Args)  is
	      evaluated	by the new process if Module:Function/Arity  does  not
	      exist (where Arity is the	length of Args). The error handler can
	      be redefined (see	process_flag/2).  If  error_handler  is	 unde-
	      fined,  or  the user has redefined the default error_handler and
	      its replacement is undefined, a failure with  reason  undef  oc-
	      curs.

	      Example:

	      >	spawn(speed, regulator,	[high_speed, thin_cut]).
	      <0.13.1>

       spawn(Node, Module, Function, Args) -> pid()

	      Types:

		 Node =	node()
		 Module	= module()
		 Function = atom()
		 Args =	[term()]

	      Returns the process identifier (pid) of a	new process started by
	      the application of Module:Function to Args on Node. If Node does
	      not  exist,  a  useless  pid  is	returned. Otherwise works like
	      spawn/3.

       spawn_link(Fun) -> pid()

	      Types:

		 Fun = function()

	      Returns the process identifier of	a new process started  by  the
	      application  of  Fun to the empty	list []. A link	is created be-
	      tween the	calling	process	and the	new process, atomically.  Oth-
	      erwise works like	spawn/3.

       spawn_link(Node,	Fun) ->	pid()

	      Types:

		 Node =	node()
		 Fun = function()

	      Returns the process identifier (pid) of a	new process started by
	      the application of Fun to	the empty list [] on Node. A  link  is
	      created  between the calling process and the new process,	atomi-
	      cally. If	Node does not exist, a useless pid is returned and  an
	      exit  signal  with  reason  noconnection	is sent	to the calling
	      process. Otherwise works like spawn/3.

       spawn_link(Module, Function, Args) -> pid()

	      Types:

		 Module	= module()
		 Function = atom()
		 Args =	[term()]

	      Returns the process identifier of	a new process started  by  the
	      application  of  Module:Function	to Args. A link	is created be-
	      tween the	calling	process	and the	new process, atomically.  Oth-
	      erwise works like	spawn/3.

       spawn_link(Node,	Module,	Function, Args)	-> pid()

	      Types:

		 Node =	node()
		 Module	= module()
		 Function = atom()
		 Args =	[term()]

	      Returns the process identifier (pid) of a	new process started by
	      the application of Module:Function to Args on Node.  A  link  is
	      created  between the calling process and the new process,	atomi-
	      cally. If	Node does not exist, a useless pid is returned and  an
	      exit  signal  with  reason  noconnection	is sent	to the calling
	      process. Otherwise works like spawn/3.

       spawn_monitor(Fun) -> {pid(), reference()}

	      Types:

		 Fun = function()

	      Returns the process identifier of	a new process, started by  the
	      application  of  Fun to the empty	list [], and a reference for a
	      monitor  created	to  the	 new  process.	Otherwise  works  like
	      spawn/3.

       spawn_monitor(Module, Function, Args) ->	{pid(),	reference()}

	      Types:

		 Module	= module()
		 Function = atom()
		 Args =	[term()]

	      A	 new  process is started by the	application of Module:Function
	      to Args. The process is monitored	at the same time. Returns  the
	      process  identifier  and	a reference for	the monitor. Otherwise
	      works like spawn/3.

       spawn_opt(Fun, Options) -> pid()	| {pid(), reference()}

	      Types:

		 Fun = function()
		 Options = [spawn_opt_option()]
		 priority_level() = low	| normal | high	| max
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}
		 message_queue_data() =	off_heap | on_heap
		 spawn_opt_option() =
		     link |
		     monitor |
		     {priority,	Level :: priority_level()} |
		     {fullsweep_after, Number :: integer() >= 0} |
		     {min_heap_size, Size :: integer() >= 0} |
		     {min_bin_vheap_size, VSize	:: integer() >=	0} |
		     {max_heap_size, Size :: max_heap_size()} |
		     {message_queue_data, MQD :: message_queue_data()}

	      Returns the process identifier (pid) of a	new process started by
	      the  application	of  Fun	 to the	empty list []. Otherwise works
	      like spawn_opt/4.

	      If option	monitor	is specified, the  newly  created  process  is
	      monitored,  and  both  the pid and reference for the monitor are
	      returned.

       spawn_opt(Node, Fun, Options) ->	pid() |	{pid(),	reference()}

	      Types:

		 Node =	node()
		 Fun = function()
		 Options = [spawn_opt_option()]
		 priority_level() = low	| normal | high	| max
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}
		 message_queue_data() =	off_heap | on_heap
		 spawn_opt_option() =
		     link |
		     monitor |
		     {priority,	Level :: priority_level()} |
		     {fullsweep_after, Number :: integer() >= 0} |
		     {min_heap_size, Size :: integer() >= 0} |
		     {min_bin_vheap_size, VSize	:: integer() >=	0} |
		     {max_heap_size, Size :: max_heap_size()} |
		     {message_queue_data, MQD :: message_queue_data()}

	      Returns the process identifier (pid) of a	new process started by
	      the  application	of  Fun	 to the	empty list [] on Node. If Node
	      does not exist, a	useless	pid is returned. Otherwise works  like
	      spawn_opt/4.

       spawn_opt(Module, Function, Args, Options) ->
		    pid() | {pid(), reference()}

	      Types:

		 Module	= module()
		 Function = atom()
		 Args =	[term()]
		 Options = [spawn_opt_option()]
		 priority_level() = low	| normal | high	| max
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}
		 message_queue_data() =	off_heap | on_heap
		 spawn_opt_option() =
		     link |
		     monitor |
		     {priority,	Level :: priority_level()} |
		     {fullsweep_after, Number :: integer() >= 0} |
		     {min_heap_size, Size :: integer() >= 0} |
		     {min_bin_vheap_size, VSize	:: integer() >=	0} |
		     {max_heap_size, Size :: max_heap_size()} |
		     {message_queue_data, MQD :: message_queue_data()}

	      Works  as	spawn/3, except	that an	extra option list is specified
	      when creating the	process.

	      If option	monitor	is specified, the  newly  created  process  is
	      monitored,  and  both  the pid and reference for the monitor are
	      returned.

	      Options:

		link:
		  Sets a link to the parent process (like spawn_link/3 does).

		monitor:
		  Monitors the new process (like monitor/2 does).

		{priority, Level}:
		  Sets the priority of the new process.	Equivalent to  execut-
		  ing  process_flag(priority,  Level) in the start function of
		  the new process, except that the priority is set before  the
		  process  is  selected	 for execution for the first time. For
		  more information on priorities,  see	process_flag(priority,
		  Level).

		{fullsweep_after, Number}:
		  Useful  only	for performance	tuning.	Do not use this	option
		  unless you know that there is	problem	with  execution	 times
		  or  memory  consumption, and ensure that the option improves
		  matters.

		  The Erlang runtime system uses a generational	 garbage  col-
		  lection  scheme,  using an "old heap"	for data that has sur-
		  vived	at least one garbage collection. When there is no more
		  room	on  the	 old  heap,  a fullsweep garbage collection is
		  done.

		  Option fullsweep_after makes it possible to specify the max-
		  imum	number	of  generational  collections before forcing a
		  fullsweep, even if there is room on the  old	heap.  Setting
		  the  number  to  zero	 disables the general collection algo-
		  rithm, that is, all live data	is  copied  at	every  garbage
		  collection.

		  A few	cases when it can be useful to change fullsweep_after:

		  * If	binaries that are no longer used are to	be thrown away
		    as soon as possible. (Set Number to	zero.)

		  * A process that mostly have short-lived data	is fullsweeped
		    seldom  or	never,	that  is, the old heap contains	mostly
		    garbage. To	ensure a fullsweep occasionally, set Number to
		    a suitable value, such as 10 or 20.

		  * In	embedded  systems  with	a limited amount of RAM	and no
		    virtual memory, you	might want to preserve memory by  set-
		    ting  Number  to zero. (The	value can be set globally, see
		    erlang:system_flag/2.)

		{min_heap_size,	Size}:
		  Useful only for performance tuning. Do not use  this	option
		  unless  you  know that there is problem with execution times
		  or memory consumption, and ensure that the  option  improves
		  matters.

		  Gives	 a  minimum  heap  size,  in words. Setting this value
		  higher than the system default can speed up  some  processes
		  because  less	garbage	collection is done. However, setting a
		  too high value can waste memory and slow down	the system be-
		  cause	 of  worse  data  locality. Therefore, use this	option
		  only for fine-tuning an application and to measure the  exe-
		  cution time with various Size	values.

		{min_bin_vheap_size, VSize}:
		  Useful  only	for performance	tuning.	Do not use this	option
		  unless you know that there is	problem	with  execution	 times
		  or  memory  consumption, and ensure that the option improves
		  matters.

		  Gives	a minimum binary virtual heap size, in words.  Setting
		  this	value higher than the system default can speed up some
		  processes because less garbage collection is done.  However,
		  setting  a  too  high	value can waste	memory.	Therefore, use
		  this option only for fine-tuning an application and to  mea-
		  sure the execution time with various VSize values.

		{max_heap_size,	Size}:
		  Sets	 the   max_heap_size   process	 flag.	 The   default
		  max_heap_size	is determined by command-line  argument	 +hmax
		  in  erl(1).  For  more information, see the documentation of
		  process_flag(max_heap_size, Size).

		{message_queue_data, MQD}:
		  Sets the state of the	message_queue_data process  flag.  MQD
		  is  to  be  either  off_heap	or  on_heap.  The default mes-
		  sage_queue_data process flag is determined  by  command-line
		  argument +hmqd in erl(1). For	more information, see the doc-
		  umentation of	process_flag(message_queue_data, MQD).

       spawn_opt(Node, Module, Function, Args, Options)	->
		    pid() | {pid(), reference()}

	      Types:

		 Node =	node()
		 Module	= module()
		 Function = atom()
		 Args =	[term()]
		 Options = [spawn_opt_option()]
		 priority_level() = low	| normal | high	| max
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}
		 message_queue_data() =	off_heap | on_heap
		 spawn_opt_option() =
		     link |
		     monitor |
		     {priority,	Level :: priority_level()} |
		     {fullsweep_after, Number :: integer() >= 0} |
		     {min_heap_size, Size :: integer() >= 0} |
		     {min_bin_vheap_size, VSize	:: integer() >=	0} |
		     {max_heap_size, Size :: max_heap_size()} |
		     {message_queue_data, MQD :: message_queue_data()}

	      Returns the process identifier (pid) of a	new process started by
	      the application of Module:Function to Args on Node. If Node does
	      not exist, a useless  pid	 is  returned.	Otherwise  works  like
	      spawn_opt/4.

	  Note:
	      Option monitor is	not supported by spawn_opt/5.

       split_binary(Bin, Pos) -> {binary(), binary()}

	      Types:

		 Bin = binary()
		 Pos = integer() >= 0
		   0..byte_size(Bin)

	      Returns  a  tuple	containing the binaries	that are the result of
	      splitting	Bin into two parts at position Pos. This is not	a  de-
	      structive	 operation. After the operation, there are three bina-
	      ries altogether. Example:

	      >	B = list_to_binary("0123456789").
	      <<"0123456789">>
	      >	byte_size(B).
	      10
	      >	{B1, B2} = split_binary(B,3).
	      {<<"012">>,<<"3456789">>}
	      >	byte_size(B1).
	      3
	      >	byte_size(B2).
	      7

       erlang:start_timer(Time,	Dest, Msg) -> TimerRef

	      Types:

		 Time =	integer() >= 0
		 Dest =	pid() |	atom()
		 Msg = term()
		 TimerRef = reference()

	      Starts a timer. The  same	 as  calling  erlang:start_timer(Time,
	      Dest, Msg, []).

       erlang:start_timer(Time,	Dest, Msg, Options) -> TimerRef

	      Types:

		 Time =	integer()
		 Dest =	pid() |	atom()
		 Msg = term()
		 Options = [Option]
		 Abs = boolean()
		 Option	= {abs,	Abs}
		 TimerRef = reference()

	      Starts  a	 timer.	 When the timer	expires, the message {timeout,
	      TimerRef,	Msg} is	sent to	the process identified by Dest.

	      Options:

		{abs, false}:
		  This is the default. It means	the Time value is  interpreted
		  as  a	time in	milliseconds relative current Erlang monotonic
		  time.

		{abs, true}:
		  Absolute Time	value. The Time	value is interpreted as	an ab-
		  solute Erlang	monotonic time in milliseconds.

	      More Options can be added	in the future.

	      The  absolute point in time, the timer is	set to expire on, must
	      be in the	interval [erlang:system_info(start_time),  erlang:sys-
	      tem_info(end_time)].  If	a relative time	is specified, the Time
	      value is not allowed to be negative.

	      If Dest is a pid(), it must be a pid() of	a process  created  on
	      the  current  runtime  system  instance. This process has	either
	      terminated or not. If Dest is an atom(), it  is  interpreted  as
	      the  name	 of a locally registered process. The process referred
	      to by the	name is	looked up at the time of timer expiration.  No
	      error is returned	if the name does not refer to a	process.

	      If  Dest	is a pid(), the	timer is automatically canceled	if the
	      process referred to by the pid() is not alive, or	if the process
	      exits.  This  feature was	introduced in ERTS 5.4.11. Notice that
	      timers are not automatically canceled when Dest is an atom().

	      See also	erlang:send_after/4,  erlang:cancel_timer/2,  and  er-
	      lang:read_timer/2.

	      Failure: badarg if the arguments do not satisfy the requirements
	      specified	here.

       statistics(Item :: active_tasks)	-> [ActiveTasks]

	      Types:

		 ActiveTasks = integer() >= 0

	      Returns the same as statistics(active_tasks_all) with the	excep-
	      tion  that  no  information about	the dirty IO run queue and its
	      associated schedulers is part of the result. That	is, only tasks
	      that are expected	to be CPU bound	are part of the	result.

       statistics(Item :: active_tasks_all) -> [ActiveTasks]

	      Types:

		 ActiveTasks = integer() >= 0

	      Returns  a  list where each element represents the amount	of ac-
	      tive processes and ports on each run queue  and  its  associated
	      schedulers.  That	is, the	number of processes and	ports that are
	      ready to run, or are currently running. Values  for  normal  run
	      queues  and their	associated schedulers are located first	in the
	      resulting	list. The first	element	corresponds to scheduler  num-
	      ber  1 and so on.	If support for dirty schedulers	exist, an ele-
	      ment with	the value for the dirty	CPU run	queue and its  associ-
	      ated  dirty  CPU	schedulers follow and then as last element the
	      value for	the the	dirty IO run queue and its associated dirty IO
	      schedulers  follow.  The information is not gathered atomically.
	      That is, the result is not necessarily a consistent snapshot  of
	      the state, but instead quite efficiently gathered.

	  Note:
	      Each  normal  scheduler  has  one	 run queue that	it manages. If
	      dirty schedulers schedulers are supported, all dirty CPU	sched-
	      ulers share one run queue, and all dirty IO schedulers share one
	      run queue. That is, we have  multiple  normal  run  queues,  one
	      dirty CPU	run queue and one dirty	IO run queue. Work can not mi-
	      grate between the	different types	of run queues.	Only  work  in
	      normal  run  queues can migrate to other normal run queues. This
	      has to be	taken into account when	evaluating the result.

	      See      also	 statistics(total_active_tasks),       statis-
	      tics(run_queue_lengths), statistics(run_queue_lengths_all), sta-
	      tistics(total_run_queue_lengths),	      and	statistics(to-
	      tal_run_queue_lengths_all).

       statistics(Item :: context_switches) -> {ContextSwitches, 0}

	      Types:

		 ContextSwitches = integer() >=	0

	      Returns  the  total  number of context switches since the	system
	      started.

       statistics(Item :: exact_reductions) ->
		     {Total_Exact_Reductions,
		      Exact_Reductions_Since_Last_Call}

	      Types:

		 Total_Exact_Reductions	=  Exact_Reductions_Since_Last_Call  =
		 integer() >= 0

	      Returns the number of exact reductions.

	  Note:
	      statistics(exact_reductions)  is a more expensive	operation than
	      statistics(reductions).

       statistics(Item :: garbage_collection) ->
		     {Number_of_GCs, Words_Reclaimed, 0}

	      Types:

		 Number_of_GCs = Words_Reclaimed = integer() >=	0

	      Returns information about	garbage	collection, for	example:

	      >	statistics(garbage_collection).
	      {85,23961,0}

	      This information can be invalid for some implementations.

       statistics(Item :: io) -> {{input, Input}, {output, Output}}

	      Types:

		 Input = Output	= integer() >= 0

	      Returns Input, which is  the  total  number  of  bytes  received
	      through  ports,  and  Output, which is the total number of bytes
	      output to	ports.

       statistics(Item :: microstate_accounting) ->
		     [MSAcc_Thread] | undefined

	      Types:

		 MSAcc_Thread =
		     #{type := MSAcc_Thread_Type,
		       id := MSAcc_Thread_Id,
		       counters	:= MSAcc_Counters}
		 MSAcc_Thread_Type =
		     async |
		     aux |
		     dirty_io_scheduler	|
		     dirty_cpu_scheduler |
		     poll |
		     scheduler
		 MSAcc_Thread_Id = integer() >=	0
		 MSAcc_Counters	= #{MSAcc_Thread_State => integer() >= 0}
		 MSAcc_Thread_State =
		     alloc |
		     aux |
		     bif |
		     busy_wait |
		     check_io |
		     emulator |
		     ets |
		     gc	|
		     gc_fullsweep |
		     nif |
		     other |
		     port |
		     send |
		     sleep |
		     timers

	      Microstate accounting can	be used	to measure how much  time  the
	      Erlang runtime system spends doing various tasks.	It is designed
	      to be as lightweight as possible,	but some overhead exists  when
	      this  is enabled.	Microstate accounting is meant to be a profil-
	      ing  tool	 to   help   finding   performance   bottlenecks.   To
	      start/stop/reset	microstate  accounting,	 use  system  flag mi-
	      crostate_accounting.

	      statistics(microstate_accounting)	returns	a list of maps	repre-
	      senting  some  of	 the OS	threads	within ERTS. Each map contains
	      type and id fields that can be used to identify what  thread  it
	      is,  and also a counters field that contains data	about how much
	      time has been spent in the various states.

	      Example:

	      >	erlang:statistics(microstate_accounting).
	      [#{counters => #{aux => 1899182914,
			       check_io	=> 2605863602,
			       emulator	=> 45731880463,
			       gc => 1512206910,
			       other =>	5421338456,
			       port => 221631,
			       sleep =>	5150294100},
		 id => 1,
		 type => scheduler}|...]

	      The time unit is the same	as returned by os:perf_counter/0.  So,
	      to convert it to milliseconds, you can do	something like this:

	      lists:map(
		fun(#{ counters	:= Cnt } = M) ->
			MsCnt =	maps:map(fun(_K, PerfCount) ->
						 erlang:convert_time_unit(PerfCount, perf_counter, 1000)
					 end, Cnt),
		       M#{ counters := MsCnt }
		end, erlang:statistics(microstate_accounting)).

	      Notice that these	values are not guaranteed to be	the exact time
	      spent in each state. This	is  because  of	 various  optimisation
	      done to keep the overhead	as small as possible.

	      MSAcc_Thread_Types:

		scheduler:
		  The main execution threads that do most of the work. See erl
		  +S for more details.

		dirty_cpu_scheduler:
		  The threads for long running cpu  intensive  work.  See  erl
		  +SDcpu for more details.

		dirty_io_scheduler:
		  The  threads	for  long  running I/O work. See erl +SDio for
		  more details.

		async:
		  Async	threads	are used by various linked-in drivers  (mainly
		  the file drivers) do offload non-CPU intensive work. See erl
		  +A for more details.

		aux:
		  Takes	care of	any work that is not specifically assigned  to
		  a scheduler.

		poll:
		  Does	the IO polling for the emulator. See erl +IOt for more
		  details.

	      The following MSAcc_Thread_States	are available. All states  are
	      exclusive,  meaning  that	 a  thread  cannot be in two states at
	      once. So,	if you add the numbers of all counters	in  a  thread,
	      you get the total	runtime	for that thread.

		aux:
		  Time spent handling auxiliary	jobs.

		check_io:
		  Time spent checking for new I/O events.

		emulator:
		  Time spent executing Erlang processes.

		gc:
		  Time	spent  doing garbage collection. When extra states are
		  enabled this is the time spent doing	non-fullsweep  garbage
		  collections.

		other:
		  Time spent doing unaccounted things.

		port:
		  Time spent executing ports.

		sleep:
		  Time spent sleeping.

	      More  fine-grained MSAcc_Thread_States can be added through con-
	      figure (such as ./configure --with-microstate-accounting=extra).
	      Enabling	these  states  causes performance degradation when mi-
	      crostate accounting is turned off	 and  increases	 the  overhead
	      when it is turned	on.

		alloc:
		  Time	spent  managing	memory.	Without	extra states this time
		  is spread out	over all other states.

		bif:
		  Time spent in	BIFs. Without extra states this	time  is  part
		  of the emulator state.

		busy_wait:
		  Time	spent  busy  waiting.  This  is	also the state where a
		  scheduler no longer reports that it  is  active  when	 using
		  statistics(scheduler_wall_time).  So,	 if  you add all other
		  states but this and sleep, and then divide that by all  time
		  in  the thread, you should get something very	similar	to the
		  scheduler_wall_time fraction.	Without	extra states this time
		  is part of the other state.

		ets:
		  Time	spent  executing  ETS  BIFs. Without extra states this
		  time is part of the emulator state.

		gc_full:
		  Time spent doing fullsweep garbage collection. Without extra
		  states this time is part of the gc state.

		nif:
		  Time	spent  in NIFs.	Without	extra states this time is part
		  of the emulator state.

		send:
		  Time spent sending messages (processes only).	Without	 extra
		  states this time is part of the emulator state.

		timers:
		  Time	spent  managing	timers.	Without	extra states this time
		  is part of the other state.

	      The utility module msacc(3) can be used to more  easily  analyse
	      these statistics.

	      Returns undefined	if system flag microstate_accounting is	turned
	      off.

	      The list of thread information is	unsorted  and  can  appear  in
	      different	order between calls.

	  Note:
	      The  threads  and	states are subject to change without any prior
	      notice.

       statistics(Item :: reductions) ->
		     {Total_Reductions,	Reductions_Since_Last_Call}

	      Types:

		 Total_Reductions = Reductions_Since_Last_Call = integer()  >=
		 0

	      Returns information about	reductions, for	example:

	      >	statistics(reductions).
	      {2046,11}

	  Note:
	      As  from ERTS 5.5	(Erlang/OTP R11B), this	value does not include
	      reductions performed in current time slices of currently	sched-
	      uled  processes. If an exact value is wanted, use	statistics(ex-
	      act_reductions).

       statistics(Item :: run_queue) ->	integer() >= 0

	      Returns the total	length of all normal run-queues. That is,  the
	      number  of  processes  and  ports	 that  are ready to run	on all
	      available	normal run-queues. Dirty run queues are	 not  part  of
	      the result. The information is gathered atomically. That is, the
	      result is	a consistent snapshot of the state, but	this operation
	      is    much    more    expensive	compared   to	statistics(to-
	      tal_run_queue_lengths), especially when a	large amount of	sched-
	      ulers is used.

       statistics(Item :: run_queue_lengths) ->	[RunQueueLength]

	      Types:

		 RunQueueLength	= integer() >= 0

	      Returns  the  same as statistics(run_queue_lengths_all) with the
	      exception	that no	information about the dirty IO	run  queue  is
	      part  of	the result. That is, only run queues with work that is
	      expected to be CPU bound is part of the result.

       statistics(Item :: run_queue_lengths_all) -> [RunQueueLength]

	      Types:

		 RunQueueLength	= integer() >= 0

	      Returns a	list where each	element	represents the amount of  pro-
	      cesses  and  ports  ready	 to run	for each run queue. Values for
	      normal run queues	are located first in the resulting  list.  The
	      first  element  corresponds to the normal	run queue of scheduler
	      number 1 and so on. If support for dirty schedulers exist,  val-
	      ues  for the dirty CPU run queue and the dirty IO	run queue fol-
	      low (in that order) at the end. The information is not  gathered
	      atomically.  That	is, the	result is not necessarily a consistent
	      snapshot of the state, but instead quite efficiently gathered.

	  Note:
	      Each normal scheduler has	one run	 queue	that  it  manages.  If
	      dirty  schedulers	schedulers are supported, all dirty CPU	sched-
	      ulers share one run queue, and all dirty IO schedulers share one
	      run  queue.  That	 is,  we  have multiple	normal run queues, one
	      dirty CPU	run queue and one dirty	IO run queue. Work can not mi-
	      grate  between  the  different types of run queues. Only work in
	      normal run queues	can migrate to other normal run	 queues.  This
	      has to be	taken into account when	evaluating the result.

	      See     also    statistics(run_queue_lengths),	statistics(to-
	      tal_run_queue_lengths_all), statistics(total_run_queue_lengths),
	      statistics(active_tasks),	statistics(active_tasks_all), and sta-
	      tistics(total_active_tasks), statistics(total_active_tasks_all).

       statistics(Item :: runtime) ->
		     {Total_Run_Time, Time_Since_Last_Call}

	      Types:

		 Total_Run_Time	= Time_Since_Last_Call = integer() >= 0

	      Returns information about	runtime, in milliseconds.

	      This is the sum of the runtime for all  threads  in  the	Erlang
	      runtime  system and can therefore	be greater than	the wall clock
	      time.

	  Warning:
	      This value might wrap due	to limitations in the underlying func-
	      tionality	provided by the	operating system that is used.

	      Example:

	      >	statistics(runtime).
	      {1690,1620}

       statistics(Item :: scheduler_wall_time) ->
		     [{SchedulerId, ActiveTime,	TotalTime}] | undefined

	      Types:

		 SchedulerId = integer() >= 1
		 ActiveTime = TotalTime	= integer() >= 0

	      Returns  a  list of tuples with {SchedulerId, ActiveTime,	Total-
	      Time}, where SchedulerId is an integer ID	of the scheduler,  Ac-
	      tiveTime is the duration the scheduler has been busy, and	Total-
	      Time is the total	time duration since scheduler_wall_time	 acti-
	      vation for the specific scheduler. Note that activation time can
	      differ significantly between schedulers. Currently dirty	sched-
	      ulers  are activated at system start while normal	schedulers are
	      activated	some time after	the scheduler_wall_time	 functionality
	      is  enabled.  The	 time  unit is undefined and can be subject to
	      change  between  releases,  OSs,	and  system  restarts.	sched-
	      uler_wall_time  is  only to be used to calculate relative	values
	      for scheduler utilization. ActiveTime can	 never	exceed	Total-
	      Time.

	      The definition of	a busy scheduler is when it is not idle	and is
	      not scheduling (selecting) a process or port, that is:

		* Executing process code

		* Executing linked-in driver or	NIF code

		* Executing BIFs, or any other runtime handling

		* Garbage collecting

		* Handling any other memory management

	      Notice that a scheduler can also be busy	even  if  the  OS  has
	      scheduled	out the	scheduler thread.

	      Returns  undefined  if system flag scheduler_wall_time is	turned
	      off.

	      The list of scheduler information	is unsorted and	can appear  in
	      different	order between calls.

	      As  of  ERTS  version 9.0, also dirty CPU	schedulers will	be in-
	      cluded in	the result. That is, all scheduler  threads  that  are
	      expected	to handle CPU bound work. If you also want information
	      about    dirty	I/O    schedulers,    use    statistics(sched-
	      uler_wall_time_all) instead.

	      Normal schedulers	will have scheduler identifiers	in the range 1
	      =_  SchedulerId  =_  erlang:system_info(schedulers).  Dirty  CPU
	      schedulers  will	have  scheduler	 identifiers  in the range er-
	      lang:system_info(schedulers)  _	SchedulerId   =_   erlang:sys-
	      tem_info(schedulers) + erlang:system_info(dirty_cpu_schedulers).

	  Note:
	      The different types of schedulers	handle specific	types of jobs.
	      Every job	is assigned to a specific scheduler type. Jobs can mi-
	      grate  between  different	schedulers of the same type, but never
	      between schedulers of different types. This fact has to be taken
	      under consideration when evaluating the result returned.

	      Using scheduler_wall_time	to calculate scheduler utilization:

	      >	erlang:system_flag(scheduler_wall_time,	true).
	      false
	      >	Ts0 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.
	      ok

	      Some  time  later	the user takes another snapshot	and calculates
	      scheduler	utilization per	scheduler, for example:

	      >	Ts1 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.
	      ok
	      >	lists:map(fun({{I, A0, T0}, {I,	A1, T1}}) -> {I, (A1 - A0)/(T1 - T0)} end, lists:zip(Ts0,Ts1)).
	      [{1,0.9743474730177548},
	       {2,0.9744843782751444},
	       {3,0.9995902361669045},
	       {4,0.9738012596572161},
	       {5,0.9717956667018103},
	       {6,0.9739235846420741},
	       {7,0.973237033077876},
	       {8,0.9741297293248656}]

	      Using the	same snapshots to calculate a total scheduler utiliza-
	      tion:

	      >	{A, T} = lists:foldl(fun({{_, A0, T0}, {_, A1, T1}}, {Ai,Ti}) -> {Ai + (A1 - A0), Ti + (T1 - T0)} end, {0, 0}, lists:zip(Ts0,Ts1)), TotalSchedulerUtilization =	A/T.
	      0.9769136803764825

	      Total  scheduler	utilization will equal 1.0 when	all schedulers
	      have been	active all the time between the	two measurements.

	      Another (probably	more)  useful  value  is  to  calculate	 total
	      scheduler	 utilization weighted against maximum amount of	avail-
	      able CPU time:

	      >	WeightedSchedulerUtilization = (TotalSchedulerUtilization * (erlang:system_info(schedulers) + erlang:system_info(dirty_cpu_schedulers))) / erlang:system_info(logical_processors_available).
	      0.9769136803764825

	      This weighted scheduler utilization will reach 1.0  when	sched-
	      ulers  are  active  the same amount of time as maximum available
	      CPU time.	If more	schedulers exist than available	 logical  pro-
	      cessors, this value may be greater than 1.0.

	      As  of  ERTS  version 9.0, the Erlang runtime system will	as de-
	      fault have more schedulers than logical processors. This due  to
	      the dirty	schedulers.

	  Note:
	      scheduler_wall_time  is  by  default disabled. To	enable it, use
	      erlang:system_flag(scheduler_wall_time, true).

       statistics(Item :: scheduler_wall_time_all) ->
		     [{SchedulerId, ActiveTime,	TotalTime}] | undefined

	      Types:

		 SchedulerId = integer() >= 1
		 ActiveTime = TotalTime	= integer() >= 0

	      The same as statistics(scheduler_wall_time), except that it also
	      include information about	all dirty I/O schedulers.

	      Dirty IO schedulers will have scheduler identifiers in the range
	      erlang:system_info(schedulers)	       +	   erlang:sys-
	      tem_info(dirty_cpu_schedulers)   _  SchedulerId  =_  erlang:sys-
	      tem_info(schedulers) +  erlang:system_info(dirty_cpu_schedulers)
	      +	erlang:system_info(dirty_io_schedulers).

	  Note:
	      Note that	work executing on dirty	I/O schedulers are expected to
	      mainly wait for I/O. That	is, when you get high  scheduler  uti-
	      lization	on  dirty  I/O	schedulers, CPU	utilization is not ex-
	      pected to	be high	due to this work.

       statistics(Item :: total_active_tasks) -> ActiveTasks

	      Types:

		 ActiveTasks = integer() >= 0

	      The same	as  calling  lists:sum(statistics(active_tasks)),  but
	      more efficient.

       statistics(Item :: total_active_tasks_all) -> ActiveTasks

	      Types:

		 ActiveTasks = integer() >= 0

	      The same as calling lists:sum(statistics(active_tasks_all)), but
	      more efficient.

       statistics(Item :: total_run_queue_lengths) ->
		     TotalRunQueueLengths

	      Types:

		 TotalRunQueueLengths =	integer() >= 0

	      The same	as  calling  lists:sum(statistics(run_queue_lengths)),
	      but more efficient.

       statistics(Item :: total_run_queue_lengths_all) ->
		     TotalRunQueueLengths

	      Types:

		 TotalRunQueueLengths =	integer() >= 0

	      The	 same	     as	       calling	     lists:sum(statis-
	      tics(run_queue_lengths_all)), but	more efficient.

       statistics(Item :: wall_clock) ->
		     {Total_Wallclock_Time,
		      Wallclock_Time_Since_Last_Call}

	      Types:

		 Total_Wallclock_Time =	Wallclock_Time_Since_Last_Call = inte-
		 ger() >= 0

	      Returns  information about wall clock. wall_clock	can be used in
	      the same manner as runtime, except that real time	is measured as
	      opposed to runtime or CPU	time.

       erlang:suspend_process(Suspendee) -> true

	      Types:

		 Suspendee = pid()

	      Suspends	the process identified by Suspendee. The same as call-
	      ing erlang:suspend_process(Suspendee, []).

	  Warning:
	      This BIF is intended for debugging only.

       erlang:suspend_process(Suspendee, OptList) -> boolean()

	      Types:

		 Suspendee = pid()
		 OptList = [Opt]
		 Opt  =	 unless_suspending  |  asynchronous  |	{asynchronous,
		 term()}

	      Increases	 the  suspend  count on	the process identified by Sus-
	      pendee and puts it in the	suspended state	if it is  not  already
	      in  that	state. A suspended process is not scheduled for	execu-
	      tion until the process has been resumed.

	      A	process	can be suspended by multiple processes and can be sus-
	      pended  multiple	times by a single process. A suspended process
	      does not leave the  suspended  state  until  its	suspend	 count
	      reaches  zero.  The suspend count	of Suspendee is	decreased when
	      erlang:resume_process(Suspendee) is called by the	 same  process
	      that  called  erlang:suspend_process(Suspendee).	All  increased
	      suspend counts on	other processes	acquired by a process are  au-
	      tomatically decreased when the process terminates.

	      Options (Opts):

		asynchronous:
		  A  suspend request is	sent to	the process identified by Sus-
		  pendee. Suspendee eventually suspends	unless it  is  resumed
		  before   it	could	suspend.  The  caller  of  erlang:sus-
		  pend_process/2 returns immediately,  regardless  of  whether
		  Suspendee  has  suspended yet	or not.	The point in time when
		  Suspendee suspends cannot be deduced from  other  events  in
		  the  system. It is only guaranteed that Suspendee eventually
		  suspends (unless it is resumed). If no asynchronous  options
		  has  been  passed, the caller	of erlang:suspend_process/2 is
		  blocked until	Suspendee has suspended.

		{asynchronous, ReplyTag}:
		  A suspend request is sent to the process identified by  Sus-
		  pendee. When the suspend request has been processed, a reply
		  message is sent to the caller	of this	function. The reply is
		  on the form {ReplyTag, State}	where State is either:

		  exited:
		    Suspendee has exited.

		  suspended:
		    Suspendee is now suspended.

		  not_suspended:
		    Suspendee  is not suspended. This can only happen when the
		    process  that  issued  this	 request,  have	  called   re-
		    sume_process(Suspendee) before getting the reply.

		  Appart  from the reply message, the {asynchronous, ReplyTag}
		  option behaves exactly the same as the  asynchronous	option
		  without reply	tag.

		unless_suspending:
		  The  process identified by Suspendee is suspended unless the
		  calling process already  is  suspending  Suspendee.  If  un-
		  less_suspending is combined with option asynchronous,	a sus-
		  pend request is sent unless the calling process  already  is
		  suspending  Suspendee	 or  if	 a suspend request already has
		  been sent and	is in transit. If the calling process  already
		  is  suspending  Suspendee,  or if combined with option asyn-
		  chronous and a send request already is in transit, false  is
		  returned  and	 the  suspend  count  on Suspendee remains un-
		  changed.

	      If the suspend count on the process identified by	 Suspendee  is
	      increased, true is returned, otherwise false.

	  Warning:
	      This BIF is intended for debugging only.

	  Warning:
	      You can easily create deadlocks if processes suspends each other
	      (directly	or in circles).	In ERTS	versions prior to ERTS version
	      10.0, the	runtime	system prevented such deadlocks, but this pre-
	      vention has now been removed due to performance reasons.

	      Failures:

		badarg:
		   If Suspendee	is not a process identifier.

		badarg:
		   If the process identified by	Suspendee is the same  process
		  as the process calling erlang:suspend_process/2.

		badarg:
		   If the process identified by	Suspendee is not alive.

		badarg:
		   If  the  process identified by Suspendee resides on another
		  node.

		badarg:
		   If OptList is not a proper list of valid Opts.

		system_limit:
		   If the process identified by	Suspendee has  been  suspended
		  more times by	the calling process than can be	represented by
		  the currently	used  internal	data  structures.  The	system
		  limit	is > 2,000,000,000 suspends and	will never be lower.

       erlang:system_flag(Flag :: backtrace_depth, Depth) -> OldDepth

	      Types:

		 Depth = OldDepth = integer() >= 0

	      Sets  the	 maximum  depth	 of call stack back-traces in the exit
	      reason element of	'EXIT' tuples. The flag	also limits the	stack-
	      trace depth returned by process_info item	current_stacktrace.

	      Returns the old value of the flag.

       erlang:system_flag(Flag :: cpu_topology,	CpuTopology) ->
			     OldCpuTopology

	      Types:

		 CpuTopology = OldCpuTopology =	cpu_topology()
		 cpu_topology()	= [LevelEntry :: level_entry()]	| undefined
		 level_entry() =
		     {LevelTag :: level_tag(), SubLevel	:: sub_level()}	|
		     {LevelTag :: level_tag(),
		      InfoList :: info_list(),
		      SubLevel :: sub_level()}
		 level_tag() = core | node | processor | thread
		 sub_level() =
		     [LevelEntry :: level_entry()] |
		     (LogicalCpuId :: {logical,	integer() >= 0})
		 info_list() = []

	  Warning:
	      This argument is deprecated. Instead of using this argument, use
	      command-line argument +sct in erl(1).

	      When this	argument is removed, a final CPU topology  to  use  is
	      determined at emulator boot time.

	      Sets the user-defined CpuTopology. The user-defined CPU topology
	      overrides	any automatically detected CPU	topology.  By  passing
	      undefined	as CpuTopology,	the system reverts to the CPU topology
	      automatically detected. The returned value equals	the value  re-
	      turned  from  erlang:system_info(cpu_topology) before the	change
	      was made.

	      Returns the old value of the flag.

	      The CPU topology is used when binding schedulers to logical pro-
	      cessors.	If  schedulers are already bound when the CPU topology
	      is changed, the schedulers are sent a request to rebind  accord-
	      ing to the new CPU topology.

	      The  user-defined	 CPU  topology can also	be set by passing com-
	      mand-line	argument +sct to erl(1).

	      For information on type CpuTopology and  more,  see  erlang:sys-
	      tem_info(cpu_topology)  as  well	as command-line	flags +sct and
	      +sbt in erl(1).

       erlang:system_flag(Flag :: dirty_cpu_schedulers_online,
			  DirtyCPUSchedulersOnline) ->
			     OldDirtyCPUSchedulersOnline

	      Types:

		 DirtyCPUSchedulersOnline = OldDirtyCPUSchedulersOnline	=  in-
		 teger() >= 1

	      Sets  the	 number	 of dirty CPU schedulers online. Range is 1 _=
	      DirtyCPUSchedulersOnline _= N, where N is	the  smallest  of  the
	      return  values  of  erlang:system_info(dirty_cpu_schedulers) and
	      erlang:system_info(schedulers_online).

	      Returns the old value of the flag.

	      The number of dirty CPU schedulers online	can change if the num-
	      ber  of schedulers online	changes. For example, if 12 schedulers
	      and 6 dirty CPU schedulers are online, and system_flag/2 is used
	      to  set the number of schedulers online to 6, then the number of
	      dirty CPU	schedulers online is automatically decreased  by  half
	      as  well,	 down  to 3. Similarly,	the number of dirty CPU	sched-
	      ulers online increases proportionally to increases in the	number
	      of schedulers online.

	      For  more	 information,  see erlang:system_info(dirty_cpu_sched-
	      ulers) and erlang:system_info(dirty_cpu_schedulers_online).

       erlang:system_flag(Flag :: erts_alloc, Value :: {Alloc, F, V}) ->
			     ok	| notsup

	      Types:

		 Alloc = F = atom()
		 V = integer()

	      Sets system flags	for erts_alloc(3). Alloc is the	 allocator  to
	      affect,  for example binary_alloc. F is the flag to change and V
	      is the new value.

	      Only a subset of all erts_alloc flags  can  be  changed  at  run
	      time. This subset	is currently only the flag sbct.

	      Returns  ok  if  the  flag was set or notsup if not supported by
	      erts_alloc.

       erlang:system_flag(Flag :: fullsweep_after, Number) -> OldNumber

	      Types:

		 Number	= OldNumber = integer()	>= 0

	      Sets system flag fullsweep_after.	Number is a non-negative inte-
	      ger  indicating  how many	times generational garbage collections
	      can be done without forcing a fullsweep  collection.  The	 value
	      applies  to  new	processes, while processes already running are
	      not affected.

	      Returns the old value of the flag.

	      In low-memory systems (especially	without	virtual	memory),  set-
	      ting the value to	0 can help to conserve memory.

	      This  value  can	also  be set through (OS) environment variable
	      ERL_FULLSWEEP_AFTER.

       erlang:system_flag(Flag :: microstate_accounting, Action) ->
			     OldState

	      Types:

		 Action	= true | false | reset
		 OldState = true | false

	      Turns on/off microstate accounting  measurements.	 When  passing
	      reset, all counters are reset to 0.

	      For more information see statistics(microstate_accounting).

       erlang:system_flag(Flag :: min_heap_size, MinHeapSize) ->
			     OldMinHeapSize

	      Types:

		 MinHeapSize = OldMinHeapSize =	integer() >= 0

	      Sets  the	 default  minimum heap size for	processes. The size is
	      specified	in words. The new min_heap_size	effects	only processes
	      spawned  after  the  change  of  min_heap_size  has  been	 made.
	      min_heap_size can	be  set	 for  individual  processes  by	 using
	      spawn_opt/4 or process_flag/2.

	      Returns the old value of the flag.

       erlang:system_flag(Flag :: min_bin_vheap_size, MinBinVHeapSize) ->
			     OldMinBinVHeapSize

	      Types:

		 MinBinVHeapSize = OldMinBinVHeapSize =	integer() >= 0

	      Sets the default minimum binary virtual heap size	for processes.
	      The size is specified in words. The new min_bin_vhheap_size  ef-
	      fects    only    processes   spawned   after   the   change   of
	      min_bin_vheap_size has been made.	min_bin_vheap_size can be  set
	      for   individual	 processes   by	  using	  spawn_opt/2,3,4   or
	      process_flag/2.

	      Returns the old value of the flag.

       erlang:system_flag(Flag :: max_heap_size, MaxHeapSize) ->
			     OldMaxHeapSize

	      Types:

		 MaxHeapSize = OldMaxHeapSize =	max_heap_size()
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}

	      Sets the default maximum heap size settings for  processes.  The
	      size  is	specified in words. The	new max_heap_size effects only
	      processes	spawned	efter the change has been made.	 max_heap_size
	      can  be  set  for	 individual processes using spawn_opt/2,3,4 or
	      process_flag/2.

	      Returns the old value of the flag.

       erlang:system_flag(Flag :: multi_scheduling, BlockState)	->
			     OldBlockState

	      Types:

		 BlockState = block | unblock |	block_normal | unblock_normal
		 OldBlockState = blocked | disabled | enabled

	      If multi-scheduling is enabled, more than	one  scheduler	thread
	      is  used by the emulator.	Multi-scheduling can be	blocked	in two
	      different	ways. Either all schedulers but	one is blocked,	or all
	      normal  schedulers  but  one is blocked. When only normal	sched-
	      ulers are	blocked, dirty schedulers  are	free  to  continue  to
	      schedule processes.

	      If  BlockState  =:= block, multi-scheduling is blocked. That is,
	      one and only one scheduler thread	will  execute.	If  BlockState
	      =:=  unblock  and	 no one	else blocks multi-scheduling, and this
	      process has blocked only once, multi-scheduling is unblocked.

	      If  BlockState  =:=  block_normal,  normal  multi-scheduling  is
	      blocked. That is,	only one normal	scheduler thread will execute,
	      but multiple dirty schedulers can	execute. If BlockState =:= un-
	      block_normal and no one else blocks normal multi-scheduling, and
	      this process has blocked only once, normal  multi-scheduling  is
	      unblocked.

	      One process can block multi-scheduling and normal	multi-schedul-
	      ing multiple times. If a process has blocked multiple times,  it
	      must  unblock  exactly as	many times as it has blocked before it
	      has released its multi-scheduling	block. If a process  that  has
	      blocked  multi-scheduling	 or  normal multi-scheduling exits, it
	      automatically releases its blocking of multi-scheduling and nor-
	      mal multi-scheduling.

	      The  return values are disabled, blocked,	blocked_normal,	or en-
	      abled. The returned value	describes the  state  just  after  the
	      call  to	erlang:system_flag(multi_scheduling,  BlockState)  has
	      been made. For information about	the  return  values,  see  er-
	      lang:system_info(multi_scheduling).

	  Note:
	      Blocking of multi-scheduling and normal multi-scheduling is nor-
	      mally not	needed.	If you feel that you need to  use  these  fea-
	      tures, consider it a few more times again. Blocking multi-sched-
	      uling is only to be used as a last resort, as it is most	likely
	      a	very inefficient way to	solve the problem.

	      See   also   erlang:system_info(multi_scheduling),   erlang:sys-
	      tem_info(normal_multi_scheduling_blockers),	   erlang:sys-
	      tem_info(multi_scheduling_blockers),	 and	   erlang:sys-
	      tem_info(schedulers).

       erlang:system_flag(Flag :: scheduler_bind_type, How) ->
			     OldBindType

	      Types:

		 How = scheduler_bind_type() | default_bind
		 OldBindType = scheduler_bind_type()
		 scheduler_bind_type() =
		     no_node_processor_spread |
		     no_node_thread_spread |
		     no_spread |
		     processor_spread |
		     spread |
		     thread_spread |
		     thread_no_node_processor_spread |
		     unbound

	  Warning:
	      This argument is deprecated. Instead of using this argument, use
	      command-line  argument +sbt in erl(1). When this argument	is re-
	      moved, a final scheduler bind type to use	is determined at  emu-
	      lator boot time.

	      Controls if and how schedulers are bound to logical processors.

	      When  erlang:system_flag(scheduler_bind_type, How) is called, an
	      asynchronous signal is sent to all  schedulers  online,  causing
	      them to try to bind or unbind as requested.

	  Note:
	      If a scheduler fails to bind, this is often silently ignored, as
	      it is not	always possible	 to  verify  valid  logical  processor
	      identifiers.  If an error	is reported, an	error event is logged.
	      To verify	that the schedulers have bound as requested, call  er-
	      lang:system_info(scheduler_bindings).

	      Schedulers  can  be  bound on newer Linux, Solaris, FreeBSD, and
	      Windows systems, but more	systems	will be	 supported  in	future
	      releases.

	      In  order	 for the runtime system	to be able to bind schedulers,
	      the CPU topology must be known. If the runtime system  fails  to
	      detect  the  CPU	topology automatically,	it can be defined. For
	      more information on how to define	the CPU	topology, see command-
	      line flag	+sct in	erl(1).

	      The  runtime system does by default not bind schedulers to logi-
	      cal processors.

	  Note:
	      If the Erlang runtime system is  the  only  OS  process  binding
	      threads  to logical processors, this improves the	performance of
	      the runtime system. However, if other OS processes (for example,
	      another Erlang runtime system) also bind threads to logical pro-
	      cessors, there can be a performance penalty  instead.  Sometimes
	      this performance penalty can be severe. If so, it	is recommended
	      to not bind the schedulers.

	      Schedulers can be	bound in different ways. Argument  How	deter-
	      mines how	schedulers are bound and can be	any of the following:

		unbound:
		  Same as command-line argument	+sbt u in erl(1).

		no_spread:
		  Same as command-line argument	+sbt ns	in erl(1).

		thread_spread:
		  Same as command-line argument	+sbt ts	in erl(1).

		processor_spread:
		  Same as command-line argument	+sbt ps	in erl(1).

		spread:
		  Same as command-line argument	+sbt s in erl(1).

		no_node_thread_spread:
		  Same as command-line argument	+sbt nnts in erl(1).

		no_node_processor_spread:
		  Same as command-line argument	+sbt nnps in erl(1).

		thread_no_node_processor_spread:
		  Same as command-line argument	+sbt tnnps in erl(1).

		default_bind:
		  Same as command-line argument	+sbt db	in erl(1).

	      The  returned  value  equals How before flag scheduler_bind_type
	      was changed.

	      Failures:

		notsup:
		  If binding of	schedulers is not supported.

		badarg:
		  If How is not	one of the documented alternatives.

		badarg:
		  If CPU topology information is unavailable.

	      The scheduler bind type can also be set by passing  command-line
	      argument +sbt to erl(1).

	      For     more    information,    see    erlang:system_info(sched-
	      uler_bind_type), erlang:system_info(scheduler_bindings), as well
	      as command-line flags +sbt and +sct in erl(1).

       erlang:system_flag(Flag :: scheduler_wall_time, Boolean)	->
			     OldBoolean

	      Types:

		 Boolean = OldBoolean =	boolean()

	      Turns on or off scheduler	wall time measurements.

	      For more information, see	statistics(scheduler_wall_time).

       erlang:system_flag(Flag :: schedulers_online, SchedulersOnline) ->
			     OldSchedulersOnline

	      Types:

		 SchedulersOnline = OldSchedulersOnline	= integer() >= 1

	      Sets  the	 number	of schedulers online. Range is 1 _= Scheduler-
	      sOnline _= erlang:system_info(schedulers).

	      Returns the old value of the flag.

	      If the emulator was built	with support  for   dirty  schedulers,
	      changing	the  number  of	 schedulers online can also change the
	      number of	dirty CPU schedulers online. For example, if 12	sched-
	      ulers  and  6 dirty CPU schedulers are online, and system_flag/2
	      is used to set the number	of schedulers online to	 6,  then  the
	      number of	dirty CPU schedulers online is automatically decreased
	      by half as well, down to 3. Similarly, the number	of  dirty  CPU
	      schedulers  online  increases proportionally to increases	in the
	      number of	schedulers online.

	      For more information, see	erlang:system_info(schedulers) and er-
	      lang:system_info(schedulers_online).

       erlang:system_flag(Flag :: system_logger, Logger) -> PrevLogger

	      Types:

		 Logger	= PrevLogger = logger |	undefined | pid()

	      Sets  the	 process that will receive the logging messages	gener-
	      ated by ERTS. If set to undefined, all logging  messages	gener-
	      ated  by	ERTS will be dropped. The messages will	be in the for-
	      mat:

	      {log,Level,Format,ArgList,Metadata} where

	      Level = atom(),
	      Format = string(),
	      ArgList =	list(term()),
	      Metadata = #{ pid	=> pid(),
		 group_leader => pid(),
		 time := logger:timestamp(),
		 error_logger := #{ emulator :=	true, tag := atom() }

	      If the system_logger process dies, this flag will	 be  reset  to
	      logger.

	      The default is the process named logger.

	      Returns the old value of the flag.

	  Note:
	      This  function  is  designed to be used by the KERNEL logger. Be
	      careful if you change it to something else as log	 messages  may
	      be  lost.	 If you	want to	intercept emulator log messages, do it
	      by adding	a specialized handler to the KERNEL logger.

       erlang:system_flag(Flag :: trace_control_word, TCW) -> OldTCW

	      Types:

		 TCW = OldTCW =	integer() >= 0

	      Sets the value of	the node trace control word to TCW,  which  is
	      to  be  an  unsigned integer. For	more information, see function
	      set_tcw in section  "Match  Specifications  in  Erlang"  in  the
	      User's Guide.

	      Returns the old value of the flag.

       erlang:system_flag(Flag :: time_offset, Value ::	finalize) ->
			     OldState

	      Types:

		 OldState = preliminary	| final	| volatile

	      Finalizes	the time offset	when single time warp mode is used. If
	      another time warp	mode is	used, the time offset  state  is  left
	      unchanged.

	      Returns the old state identifier,	that is:

		* If  preliminary  is returned,	finalization was performed and
		  the time offset is now final.

		* If final is returned,	the time offset	was already in the fi-
		  nal	state.	 This	either	 because  another  erlang:sys-
		  tem_flag(time_offset,	finalize) call or because no time warp
		  mode is used.

		* If volatile is returned, the time offset cannot be finalized
		  because multi-time warp mode is used.

       erlang:system_info(Item ::
			      wordsize |
			      {wordsize, internal} |
			      {wordsize, external}) ->
			     4 | 8

	      Returns information about	the current system. The	 documentation
	      of  this function	is broken into the following sections in order
	      to make it easier	to navigate.

		Memory Allocation:
		  allocated_areas, allocator,  alloc_util_allocators,  alloca-
		  tor_sizes, elib_malloc

		CPU Topology:
		  cpu_topology,	logical_processors, update_cpu_info

		Process	Information:
		  fullsweep_after,  garbage_collection,	heap_sizes, heap_type,
		  max_heap_size,      message_queue_data,	min_heap_size,
		  min_bin_vheap_size, procs

		System Limits:
		  atom_count,  atom_limit,  ets_count,	ets_limit, port_count,
		  port_limit, process_count, process_limit

		System Time:
		  end_time,  os_monotonic_time_source,	os_system_time_source,
		  start_time,  time_correction,	 time_offset,  time_warp_mode,
		  tolerant_timeofday

		Scheduler Information:
		  dirty_cpu_schedulers,		  dirty_cpu_schedulers_online,
		  dirty_io_schedulers,	   multi_scheduling,	multi_schedul-
		  ing_blockers,	   normal_multi_scheduling_blockers,	sched-
		  uler_bind_type,   scheduler_bindings,	 scheduler_id,	sched-
		  ulers, smp_support, threads, thread_pool_size

		Distribution Information:
		  creation, delayed_node_table_gc, dist,  dist_buf_busy_limit,
		  dist_ctrl

		System Information:
		  build_type,	c_compiler_used,   check_io,  compat_rel,  de-
		  bug_compiled,	    driver_version,	dynamic_trace,	   dy-
		  namic_trace_probes, info, kernel_poll, loaded, machine, mod-
		  ified_timing_level, nif_version, otp_release,	port_parallel-
		  ism,	 system_architecture,  system_logger,  system_version,
		  trace_control_word, version, wordsize

       erlang:system_info(Item :: allocated_areas) -> [tuple()]

       erlang:system_info(Item :: allocator) ->
			     {Allocator, Version, Features, Settings}

       erlang:system_info(Item :: {allocator, Alloc}) -> [term()]

       erlang:system_info(Item :: alloc_util_allocators) -> [Alloc]

       erlang:system_info(Item :: {allocator_sizes, Alloc}) -> [term()]

       erlang:system_info(Item :: elib_malloc) -> false

	      Types:

		 Allocator = undefined | glibc
		 Version = [integer() >= 0]
		 Features = [atom()]
		 Settings =
		     [{Subsystem :: atom(),
		       [{Parameter :: atom(), Value :: term()}]}]
		 Alloc = atom()

	      Returns various information about	the memory allocators  of  the
	      current system (emulator)	as specified by	Item:

		allocated_areas:
		  Returns  a  list  of tuples with information about miscella-
		  neous	allocated memory areas.

		  Each tuple contains an atom describing the type of memory as
		  first	element	and the	amount of allocated memory in bytes as
		  second element. When information about  allocated  and  used
		  memory is present, also a third element is present, contain-
		  ing the amount of used memory	in bytes.

		  erlang:system_info(allocated_areas) is intended  for	debug-
		  ging,	 and  the  content is highly implementation-dependent.
		  The content of the results  therefore	 changes  when	needed
		  without prior	notice.

		  Notice  that the sum of these	values is not the total	amount
		  of memory allocated by the emulator. Some values are part of
		  other	 values, and some memory areas are not part of the re-
		  sult.	For information	about the total	amount of memory allo-
		  cated	by the emulator, see erlang:memory/0,1.

		allocator:
		  Returns {Allocator, Version, Features, Settings, where:

		  * Allocator corresponds to the malloc() implementation used.
		    If Allocator equals	undefined, the malloc()	implementation
		    used cannot	be identified. glibc can be identified.

		  * Version  is	 a  list of integers (but not a	string)	repre-
		    senting the	version	of the malloc()	implementation used.

		  * Features is	a list of atoms	 representing  the  allocation
		    features used.

		  * Settings  is  a list of subsystems,	their configurable pa-
		    rameters, and used values.	Settings  can  differ  between
		    different combinations of platforms, allocators, and allo-
		    cation features. Memory sizes are given in bytes.

		  See also "System Flags  Effecting  erts_alloc"  in  erts_al-
		  loc(3).

		{allocator, Alloc}:
		  Returns  information	about the specified allocator. As from
		  ERTS 5.6.1, the return value is a list of {instance, Instan-
		  ceNo,	 InstanceInfo} tuples, where InstanceInfo contains in-
		  formation about a specific instance of the allocator.	If Al-
		  loc is not a recognized allocator, undefined is returned. If
		  Alloc	is disabled, false is returned.

		  Notice that the information returned is  highly  implementa-
		  tion-dependent  and  can  be	changed	or removed at any time
		  without prior	notice.	It was initially intended  as  a  tool
		  when developing new allocators, but as it can	be of interest
		  for others it	has been briefly documented.

		  The recognized allocators are	listed in  erts_alloc(3).  In-
		  formation about super	carriers can be	obtained from ERTS 8.0
		  with {allocator, erts_mmap} or from  ERTS  5.10.4;  the  re-
		  turned  list	when calling with {allocator, mseg_alloc} also
		  includes an {erts_mmap, _} tuple as one element in the list.

		  After	reading	the erts_alloc(3) documentation, the  returned
		  information  more  or	 less speaks for itself, but it	can be
		  worth	explaining some	things.	Call counts are	 presented  by
		  two  values,	the  first value is giga calls,	and the	second
		  value	is calls. mbcs and sbcs	denote	multi-block  carriers,
		  and single-block carriers, respectively. Sizes are presented
		  in bytes. When a size	is not presented, it is	the amount  of
		  something.  Sizes  and  amounts are often presented by three
		  values:

		  * The	first is the current value.

		  * The	second is the maximum value since the last call	to er-
		    lang:system_info({allocator, Alloc}).

		  * The	 third	is  the	 maximum  value	since the emulator was
		    started.

		  If only one value is	present,  it  is  the  current	value.
		  fix_alloc  memory  block  types are presented	by two values.
		  The first value is the memory	pool size and the second value
		  is the used memory size.

		alloc_util_allocators:
		  Returns a list of the	names of all allocators	using the ERTS
		  internal alloc_util framework	as atoms.  For	more  informa-
		  tion,	see section The	alloc_util framework in	erts_alloc(3).

		{allocator_sizes, Alloc}:
		  Returns  various  size information for the specified alloca-
		  tor. The information returned	is a subset of the information
		  returned by erlang:system_info({allocator, Alloc}).

		elib_malloc:
		  This	option will be removed in a future release. The	return
		  value	will always be false, as the elib_malloc allocator has
		  been removed.

       erlang:system_info(Item :: cpu_topology)	-> CpuTopology

       erlang:system_info(Item ::
			      {cpu_topology, defined | detected	| used}) ->
			     CpuTopology

       erlang:system_info(Item ::
			      logical_processors |
			      logical_processors_available |
			      logical_processors_online) ->
			     unknown | integer() >= 1

       erlang:system_info(Item :: update_cpu_info) -> changed |	unchanged

	      Types:

		 cpu_topology()	= [LevelEntry :: level_entry()]	| undefined
		    All	 LevelEntrys of	a list must contain the	same LevelTag,
		   except on the top level  where  both	 node  and  processor-
		   LevelTags can coexist.
		 level_entry() =
		     {LevelTag :: level_tag(), SubLevel	:: sub_level()}	|
		     {LevelTag :: level_tag(),
		      InfoList :: info_list(),
		      SubLevel :: sub_level()}
		   {LevelTag, SubLevel}	== {LevelTag, [], SubLevel}
		 level_tag() = core | node | processor | thread
		    More LevelTags can be introduced in	a future release.
		 sub_level() =
		     [LevelEntry :: level_entry()] |
		     (LogicalCpuId :: {logical,	integer() >= 0})
		 info_list() = []
		    The	info_list() can	be extended in a future	release.

	      Returns  various	information about the CPU topology of the cur-
	      rent system (emulator) as	specified by Item:

		cpu_topology:
		  Returns the CpuTopology currently used by the	emulator.  The
		  CPU topology is used when binding schedulers to logical pro-
		  cessors. The CPU topology  used  is  the   user-defined  CPU
		  topology,  if	 such exists, otherwise	the  automatically de-
		  tected CPU topology, if such exists. If no CPU topology  ex-
		  ists,	undefined is returned.

		  node	refers	to  Non-Uniform	 Memory	 Access	 (NUMA)	nodes.
		  thread refers	to hardware threads (for example, Intel	hyper-
		  threads).

		  A level in term CpuTopology can be omitted if	only one entry
		  exists and InfoList is empty.

		  thread can only be a sublevel	to core. core can  be  a  sub-
		  level	 to  processor	or  node.  processor can be on the top
		  level	or a sublevel to node. node can	be on the top level or
		  a  sublevel to processor. That is, NUMA nodes	can be proces-
		  sor internal or processor external. A	CPU topology can  con-
		  sist of a mix	of processor internal and external NUMA	nodes,
		  as long as each logical CPU belongs to one NUMA node.	 Cache
		  hierarchy  is	 not part of the CpuTopology type, but will be
		  in a future release. Other things can	also make it into  the
		  CPU topology in a future release. So,	expect the CpuTopology
		  type to change.

		{cpu_topology, defined}:

		  Returns the user-defined CpuTopology.	For more  information,
		  see command-line flag	+sct in	erl(1) and argument cpu_topol-
		  ogy.

		{cpu_topology, detected}:

		  Returns the automatically detected CpuTopologyy. The	emula-
		  tor  detects	the CPU	topology on some newer Linux, Solaris,
		  FreeBSD, and Windows systems.	On Windows  system  with  more
		  than	32  logical  processors,  the  CPU topology is not de-
		  tected.

		  For more information,	see argument cpu_topology.

		{cpu_topology, used}:
		  Returns CpuTopology used by the emulator. For	more  informa-
		  tion,	see argument cpu_topology.

		logical_processors:
		  Returns the detected number of logical processors configured
		  in the system. The return value is either an integer,	or the
		  atom	unknown	 if  the emulator cannot detect	the configured
		  logical processors.

		logical_processors_available:
		  Returns the detected number of logical processors  available
		  to  the Erlang runtime system. The return value is either an
		  integer, or the atom unknown if the emulator	cannot	detect
		  the  available  logical  processors. The number of available
		  logical processors is	less than or equal to  the  number  of
		  logical processors online.

		logical_processors_online:
		  Returns  the detected	number of logical processors online on
		  the system. The return value is either an  integer,  or  the
		  atom	unknown	 if the	emulator cannot	detect logical proces-
		  sors online. The number of logical processors	online is less
		  than	or  equal  to the number of logical processors config-
		  ured.

		update_cpu_info:
		  The runtime system rereads the CPU information available and
		  updates its internally stored	information about the detected
		  CPU topology and the number of  logical  processors  config-
		  ured,	online,	and  available.

		  If  the  CPU	information has	changed	since the last time it
		  was read, the	atom changed is	returned, otherwise  the  atom
		  unchanged.  If the CPU information has changed, you probably
		  want to adjust the number of schedulers  online.  You	 typi-
		  cally	want to	have as	many schedulers	online as logical pro-
		  cessors available.

       erlang:system_info(Item :: fullsweep_after) ->
			     {fullsweep_after, integer() >= 0}

       erlang:system_info(Item :: garbage_collection) ->
			     [{atom(), integer()}]

       erlang:system_info(Item :: heap_sizes) -> [integer() >= 0]

       erlang:system_info(Item :: heap_type) ->	private

       erlang:system_info(Item :: max_heap_size) ->
			     {max_heap_size,
			      MaxHeapSize :: max_heap_size()}

       erlang:system_info(Item :: message_queue_data) ->
			     message_queue_data()

       erlang:system_info(Item :: min_heap_size) ->
			     {min_heap_size,
			      MinHeapSize :: integer() >= 1}

       erlang:system_info(Item :: min_bin_vheap_size) ->
			     {min_bin_vheap_size,
			      MinBinVHeapSize :: integer() >= 1}

       erlang:system_info(Item :: procs) -> binary()

	      Types:

		 message_queue_data() =	off_heap | on_heap
		 max_heap_size() =
		     integer() >= 0 |
		     #{size => integer() >= 0,
		       kill => boolean(),
		       error_logger => boolean()}

	      Returns information about	the default process heap settings:

		fullsweep_after:
		  Returns {fullsweep_after, integer()  _=  0},	which  is  the
		  fullsweep_after  garbage collection setting used by default.
		  For more information,	see garbage_collection	described  be-
		  low.

		garbage_collection:
		  Returns  a  list  describing	the default garbage collection
		  settings. A process spawned on the local node	by a spawn  or
		  spawn_link  uses  these garbage collection settings. The de-
		  fault	settings can be	changed	by using erlang:system_flag/2.
		  spawn_opt/2,3,4  can	spawn  a process that does not use the
		  default settings.

		heap_sizes:
		  Returns a list of integers representing valid	heap sizes  in
		  words. All Erlang heaps are sized from sizes in this list.

		heap_type:
		  Returns the heap type	used by	the current emulator. One heap
		  type exists:

		  private:
		     Each process has a	heap reserved for its use and no  ref-
		    erences  between heaps of different	processes are allowed.
		    Messages  passed  between  processes  are  copied  between
		    heaps.

		max_heap_size:
		  Returns  {max_heap_size,  MaxHeapSize}, where	MaxHeapSize is
		  the current  system-wide  maximum  heap  size	 settings  for
		  spawned  processes.  This  setting can be set	using the com-
		  mand-line flags +hmax, +hmaxk	and +hmaxel in erl(1). It  can
		  also	  be	changed	   at	 runtime   using   erlang:sys-
		  tem_flag(max_heap_size, MaxHeapSize).	For more details about
		  the	     max_heap_size	 process       flag,	   see
		  process_flag(max_heap_size, MaxHeapSize).

		message_queue_data:
		  Returns the default value of the message_queue_data  process
		  flag,	 which	is either off_heap or on_heap. This default is
		  set by command-line argument +hmqd in	erl(1).	For  more  in-
		  formation  on	the message_queue_data process flag, see docu-
		  mentation of process_flag(message_queue_data,	MQD).

		min_heap_size:
		  Returns {min_heap_size, MinHeapSize},	where  MinHeapSize  is
		  the  current	system-wide minimum heap size for spawned pro-
		  cesses.

		min_bin_vheap_size:
		  Returns {min_bin_vheap_size, MinBinVHeapSize}, where MinBin-
		  VHeapSize  is	the current system-wide	minimum	binary virtual
		  heap size for	spawned	processes.

		procs:
		  Returns a binary containing a	string of process and port in-
		  formation  formatted	as in Erlang crash dumps. For more in-
		  formation, see section  How to interpret  the	 Erlang	 crash
		  dumps	in the User's Guide.

       erlang:system_info(Item :: atom_count) -> integer() >= 1

       erlang:system_info(Item :: atom_limit) -> integer() >= 1

       erlang:system_info(Item :: ets_count) ->	integer() >= 1

       erlang:system_info(Item :: ets_limit) ->	integer() >= 1

       erlang:system_info(Item :: port_count) -> integer() >= 0

       erlang:system_info(Item :: port_limit) -> integer() >= 1

       erlang:system_info(Item :: process_count) -> integer() >= 1

       erlang:system_info(Item :: process_limit) -> integer() >= 1

	      Returns  information  about the current system (emulator)	limits
	      as specified by Item:

		atom_count:
		  Returns the number of	atoms currently	existing at the	 local
		  node.	The value is given as an integer.

		atom_limit:
		  Returns  the maximum number of atoms allowed.	This limit can
		  be increased at startup by passing command-line flag	+t  to
		  erl(1).

		ets_count:
		  Returns  the	number of ETS tables currently existing	at the
		  local	node.

		ets_limit:
		  Returns the limit for	number of ETS tables.  This  limit  is
		  partially  obsolete and number of tables are only limited by
		  available memory.

		port_count:
		  Returns the number of	ports currently	existing at the	 local
		  node.	 The  value  is	 given as an integer. This is the same
		  value	as returned by length(erlang:ports()), but more	 effi-
		  cient.

		port_limit:
		  Returns  the maximum number of simultaneously	existing ports
		  at the local node as an integer. This	limit can  be  config-
		  ured at startup by using command-line	flag +Q	in erl(1).

		process_count:
		  Returns  the	number	of processes currently existing	at the
		  local	node. The value	is given as an integer.	 This  is  the
		  same	value as returned by length(processes()), but more ef-
		  ficient.

		process_limit:
		  Returns the maximum number of	simultaneously	existing  pro-
		  cesses  at the local node. The value is given	as an integer.
		  This limit can be configured at startup  by  using  command-
		  line flag +P in erl(1).

       erlang:system_info(Item :: end_time) -> integer() >= 0

       erlang:system_info(Item :: os_monotonic_time_source) ->
			     [{atom(), term()}]

       erlang:system_info(Item :: os_system_time_source) ->
			     [{atom(), term()}]

       erlang:system_info(Item :: start_time) -> integer()

       erlang:system_info(Item :: time_correction) -> true | false

       erlang:system_info(Item :: time_offset) ->
			     preliminary | final | volatile

       erlang:system_info(Item :: time_warp_mode) ->
			     no_time_warp |
			     single_time_warp |
			     multi_time_warp

       erlang:system_info(Item :: tolerant_timeofday) ->
			     enabled | disabled

	      Returns  information about the current system (emulator) time as
	      specified	by Item:

		end_time:
		  The last Erlang monotonic time in native time	unit that  can
		  be represented internally in the current Erlang runtime sys-
		  tem instance.	The time between the start time	 and  the  end
		  time is at least a quarter of	a millennium.

		os_monotonic_time_source:
		  Returns a list containing information	about the source of OS
		  monotonic time that is used by the runtime system.

		  If []	is returned, no	OS monotonic time  is  available.  The
		  list	contains  two-tuples  with  Keys as first element, and
		  Values as second element. The	order of these tuples is unde-
		  fined.  The  following  tuples  can be part of the list, but
		  more tuples can be introduced	in the future:

		  {function, Function}:
		    Function is	the name of the	function used. This tuple  al-
		    ways  exists if OS monotonic time is available to the run-
		    time system.

		  {clock_id, ClockId}:
		    This tuple only exists if Function can be used  with  dif-
		    ferent clocks. ClockId corresponds to the clock identifier
		    used when calling Function.

		  {resolution, OsMonotonicTimeResolution}:
		    Highest possible  resolution of current OS monotonic  time
		    source  as	parts per second. If no	resolution information
		    can	be retrieved from the OS, OsMonotonicTimeResolution is
		    set	to the resolution of the time unit of Functions	return
		    value. That	is, the	actual resolution can  be  lower  than
		    OsMonotonicTimeResolution. Notice that the resolution does
		    not	say anything about the	accuracy or whether the	  pre-
		    cision  aligns  with the resolution. You do, however, know
		    that the precision is not better than OsMonotonicTimeReso-
		    lution.

		  {extended, Extended}:
		    Extended  equals  yes if the range of time values has been
		    extended; otherwise	Extended equals	no. The	range must  be
		    extended  if  Function returns values that wrap fast. This
		    typically is the case when the return value	 is  a	32-bit
		    value.

		  {parallel, Parallel}:
		    Parallel equals yes	if Function is called in parallel from
		    multiple threads. If it is not called in parallel, because
		    calls must be serialized, Parallel equals no.

		  {time, OsMonotonicTime}:
		    OsMonotonicTime equals current OS monotonic	time in	native
		    time unit.

		os_system_time_source:
		  Returns a list containing information	about the source of OS
		  system time that is used by the runtime system.

		  The list contains two-tuples with Keys as first element, and
		  Values as second element. The	order of these tuples is unde-
		  fined.  The  following  tuples  can be part of the list, but
		  more tuples can be introduced	in the future:

		  {function, Function}:
		    Function is	the name of the	funcion	used.

		  {clock_id, ClockId}:
		    Exists only	if Function can	be used	with different clocks.
		    ClockId  corresponds  to  the  clock  identifier used when
		    calling Function.

		  {resolution, OsSystemTimeResolution}:
		    Highest possible  resolution of  current  OS  system  time
		    source  as	parts per second. If no	resolution information
		    can	be retrieved from the  OS,  OsSystemTimeResolution  is
		    set	to the resolution of the time unit of Functions	return
		    value. That	is, the	actual resolution can  be  lower  than
		    OsSystemTimeResolution.  Notice  that  the resolution does
		    not	say anything about the	accuracy or whether the	  pre-
		    cision do align with the resolution. You do, however, know
		    that the precision is not better than  OsSystemTimeResolu-
		    tion.

		  {parallel, Parallel}:
		    Parallel equals yes	if Function is called in parallel from
		    multiple threads. If it is not called in parallel, because
		    calls needs	to be serialized, Parallel equals no.

		  {time, OsSystemTime}:
		    OsSystemTime  equals current OS system time	in native time
		    unit.

		start_time:
		  The Erlang monotonic time in native time unit	 at  the  time
		  when current Erlang runtime system instance started.

		  See also erlang:system_info(end_time).

		time_correction:
		  Returns  a boolean value indicating whether  time correction
		  is enabled or	not.

		time_offset:
		  Returns the state of the time	offset:

		  preliminary:
		    The	time offset is preliminary, and	will  be  changed  and
		    finalized  later. The preliminary time offset is used dur-
		    ing	the preliminary	phase of the  single time warp mode.

		  final:
		    The	time offset is final. This  either  because   no  time
		    warp  mode	is  used, or because the time offset have been
		    finalized when  single time	warp mode is used.

		  volatile:
		    The	time offset is volatile. That is, it can change	at any
		    time. This is because  multi-time warp mode	is used.

		time_warp_mode:
		  Returns  a  value  identifying  the	time warp mode that is
		  used:

		  no_time_warp:
		    The	 no time warp mode is used.

		  single_time_warp:
		    The	 single	time warp mode is used.

		  multi_time_warp:
		    The	 multi-time warp mode is used.

		tolerant_timeofday:
		  Returns whether a pre	ERTS 7.0 backwards compatible  compen-
		  sation  for sudden changes of	system time is enabled or dis-
		  abled. Such compensation is enabled when the time offset  is
		  final, and  time correction is enabled.

       erlang:system_info(Item :: dirty_cpu_schedulers)	->
			     integer() >= 0

       erlang:system_info(Item :: dirty_cpu_schedulers_online) ->
			     integer() >= 0

       erlang:system_info(Item :: dirty_io_schedulers) ->
			     integer() >= 0

       erlang:system_info(Item :: multi_scheduling) ->
			     disabled |
			     blocked |
			     blocked_normal |
			     enabled

       erlang:system_info(Item :: multi_scheduling_blockers) ->
			     [Pid :: pid()]

       erlang:system_info(Item :: otp_release) -> string()

       erlang:system_info(Item :: scheduler_bind_type) ->
			     spread |
			     processor_spread |
			     thread_spread |
			     thread_no_node_processor_spread |
			     no_node_processor_spread |
			     no_node_thread_spread |
			     no_spread |
			     unbound

       erlang:system_info(Item :: scheduler_bindings) -> tuple()

       erlang:system_info(Item :: scheduler_id)	->
			     SchedulerId :: integer() >= 1

       erlang:system_info(Item :: schedulers | schedulers_online) ->
			     integer() >= 1

       erlang:system_info(Item :: smp_support) -> boolean()

       erlang:system_info(Item :: threads) -> boolean()

       erlang:system_info(Item :: thread_pool_size) -> integer() >= 0

	      Returns  information about schedulers, scheduling	and threads in
	      the current system as specified by Item:

		dirty_cpu_schedulers:
		  Returns the number of	dirty CPU scheduler  threads  used  by
		  the  emulator. Dirty CPU schedulers execute CPU-bound	native
		  functions, such as NIFs, linked-in  driver  code,  and  BIFs
		  that cannot be managed cleanly by the	normal emulator	sched-
		  ulers.

		  The number of	dirty CPU scheduler threads is	determined  at
		  emulator  boot  time	and cannot be changed after that. How-
		  ever,	the number of dirty CPU	scheduler threads  online  can
		  be  changed  at any time. The	number of dirty	CPU schedulers
		  can be set at	startup	by passing command-line	flag +SDcpu or
		  +SDPcpu in erl(1).

		  See	also   erlang:system_flag(dirty_cpu_schedulers_online,
		  DirtyCPUSchedulersOnline),			   erlang:sys-
		  tem_info(dirty_cpu_schedulers_online),	   erlang:sys-
		  tem_info(dirty_io_schedulers),     erlang:system_info(sched-
		  ulers),   erlang:system_info(schedulers_online),   and   er-
		  lang:system_flag(schedulers_online, SchedulersOnline).

		dirty_cpu_schedulers_online:
		  Returns the number of	dirty CPU schedulers online.  The  re-
		  turn	value  satisfies  1  _=	DirtyCPUSchedulersOnline _= N,
		  where	N is the smallest of the return	values of  erlang:sys-
		  tem_info(dirty_cpu_schedulers) and erlang:system_info(sched-
		  ulers_online).

		  The number of	dirty CPU schedulers  online  can  be  set  at
		  startup by passing command-line flag +SDcpu in erl(1).

		  For	    more       information,	  see	   erlang:sys-
		  tem_info(dirty_cpu_schedulers),		   erlang:sys-
		  tem_info(dirty_io_schedulers),     erlang:system_info(sched-
		  ulers_online),    and	   erlang:system_flag(dirty_cpu_sched-
		  ulers_online,	DirtyCPUSchedulersOnline).

		dirty_io_schedulers:
		  Returns  the	number	of dirty I/O schedulers	as an integer.
		  Dirty	I/O schedulers	execute	 I/O-bound  native  functions,
		  such as NIFs and linked-in driver code, which	cannot be man-
		  aged cleanly by the normal emulator schedulers.

		  This value can be set	at startup by passing command-line ar-
		  gument +SDio in erl(1).

		  For	    more       information,	  see	   erlang:sys-
		  tem_info(dirty_cpu_schedulers),		   erlang:sys-
		  tem_info(dirty_cpu_schedulers_online),    and	   erlang:sys-
		  tem_flag(dirty_cpu_schedulers_online,	 DirtyCPUSchedulersOn-
		  line).

		multi_scheduling:
		  Returns one of the following:

		  disabled:
		    The	 emulator  has	been  started  with only one scheduler
		    thread.

		  blocked:
		    The	emulator has more than one scheduler thread,  but  all
		    scheduler  threads	except	one are	blocked. That is, only
		    one	scheduler thread schedules Erlang processes  and  exe-
		    cutes Erlang code.

		  blocked_normal:
		    The	 emulator  has more than one scheduler thread, but all
		    normal scheduler threads except one	 are  blocked.	Notice
		    that  dirty	 schedulers  are not blocked, and can schedule
		    Erlang processes and execute native	code.

		  enabled:
		    The	emulator has more than one scheduler  thread,  and  no
		    scheduler  threads	are  blocked.  That  is, all available
		    scheduler threads schedule Erlang  processes  and  execute
		    Erlang code.

		  See  also  erlang:system_flag(multi_scheduling, BlockState),
		  erlang:system_info(multi_scheduling_blockers),   erlang:sys-
		  tem_info(normal_multi_scheduling_blockers),  and erlang:sys-
		  tem_info(schedulers).

		multi_scheduling_blockers:
		  Returns a list of Pids  when	multi-scheduling  is  blocked,
		  otherwise  the  empty	list is	returned. The Pids in the list
		  represent all	the processes currently	blocking  multi-sched-
		  uling.  A Pid	occurs only once in the	list, even if the cor-
		  responding process has blocked multiple times.

		  See also  erlang:system_flag(multi_scheduling,  BlockState),
		  erlang:system_info(multi_scheduling),		   erlang:sys-
		  tem_info(normal_multi_scheduling_blockers), and  erlang:sys-
		  tem_info(schedulers).

		normal_multi_scheduling_blockers:
		  Returns  a  list  of	Pids  when  normal multi-scheduling is
		  blocked (that	is, all	normal schedulers but one is blocked),
		  otherwise  the  empty	list is	returned. The Pids in the list
		  represent all	the processes currently	blocking normal	multi-
		  scheduling.  A Pid occurs only once in the list, even	if the
		  corresponding	process	has blocked multiple times.

		  See also  erlang:system_flag(multi_scheduling,  BlockState),
		  erlang:system_info(multi_scheduling),		   erlang:sys-
		  tem_info(multi_scheduling_blockers),	   and	   erlang:sys-
		  tem_info(schedulers).

		scheduler_bind_type:
		  Returns  information about how the user has requested	sched-
		  ulers	to be bound or not bound.

		  Notice that although a user has requested schedulers	to  be
		  bound, they can silently have	failed to bind.	To inspect the
		  scheduler bindings, call  erlang:system_info(scheduler_bind-
		  ings).

		  For  more  information,  see	command-line  argument +sbt in
		  erl(1) and erlang:system_info(scheduler_bindings).

		scheduler_bindings:
		  Returns information about the	currently used scheduler bind-
		  ings.

		  A tuple of a size equal to erlang:system_info(schedulers) is
		  returned. The	tuple elements are integers or	the  atom  un-
		  bound.  Logical processor identifiers	are represented	as in-
		  tegers. The Nth element of  the  tuple  equals  the  current
		  binding  for	the  scheduler	with  the scheduler identifier
		  equal	to N. For example, if the schedulers are  bound,  ele-
		  ment(erlang:system_info(scheduler_id),	   erlang:sys-
		  tem_info(scheduler_bindings))	returns	the identifier of  the
		  logical processor that the calling process is	executing on.

		  Notice  that	only schedulers	online can be bound to logical
		  processors.

		  For more information,	 see  command-line  argument  +sbt  in
		  erl(1) and erlang:system_info(schedulers_online).

		scheduler_id:
		  Returns  the	scheduler  ID  (SchedulerId)  of the scheduler
		  thread that the calling process is executing on. SchedulerId
		  is a positive	integer, where 1 _= SchedulerId	_= erlang:sys-
		  tem_info(schedulers).

		  See also erlang:system_info(schedulers).

		schedulers:
		  Returns the number of	scheduler threads used by  the	emula-
		  tor. Scheduler threads online	schedules Erlang processes and
		  Erlang ports,	and execute Erlang code	and  Erlang  linked-in
		  driver code.

		  The  number  of  scheduler threads is	determined at emulator
		  boot time and	cannot be changed later. However,  the	number
		  of schedulers	online can be changed at any time.

		  See also erlang:system_flag(schedulers_online, SchedulersOn-
		  line),  erlang:system_info(schedulers_online),   erlang:sys-
		  tem_info(scheduler_id), erlang:system_flag(multi_scheduling,
		  BlockState),	  erlang:system_info(multi_scheduling),	   er-
		  lang:system_info(normal_multi_scheduling_blockers)  and  er-
		  lang:system_info(multi_scheduling_blockers).

		schedulers_online:
		  Returns the number of	schedulers online. The scheduler iden-
		  tifiers  of  schedulers online satisfy the relationship 1 _=
		  SchedulerId _= erlang:system_info(schedulers_online).

		  For more information,	see erlang:system_info(schedulers) and
		  erlang:system_flag(schedulers_online,	SchedulersOnline).

		smp_support:
		  Returns true.

		threads:
		  Returns true.

		thread_pool_size:

		  Returns the number of	async threads in the async thread pool
		  used	     for       asynchronous	   driver	 calls
		  (erl_driver:driver_async()).	The value is given as an inte-
		  ger.

       erlang:system_info(Item :: creation) -> integer()

       erlang:system_info(Item :: delayed_node_table_gc) ->
			     infinity |	integer() >= 0

       erlang:system_info(Item :: dist)	-> binary()

       erlang:system_info(Item :: dist_buf_busy_limit) ->
			     integer() >= 0

       erlang:system_info(Item :: dist_ctrl) ->
			     {Node :: node(),
			      ControllingEntity	:: port() | pid()}

	      Returns information about	Erlang	Distribution  in  the  current
	      system as	specified by Item:

		creation:
		  Returns  the	creation  of the local node as an integer. The
		  creation is changed when a node is restarted.	 The  creation
		  of  a	 node  is  stored in process identifiers, port identi-
		  fiers, and references. This makes it (to some	extent)	possi-
		  ble to distinguish between identifiers from different	incar-
		  nations of a node. The valid creations are integers  in  the
		  range	 1..3,	but  this will probably	change in a future re-
		  lease. If the	node is	not alive, 0 is	returned.

		delayed_node_table_gc:
		  Returns the amount of	time in	seconds	garbage	collection  of
		  an  entry  in	a node table is	delayed. This limit can	be set
		  on startup by	passing	command-line flag +zdntgc  to  erl(1).
		  For  more information, see the documentation of the command-
		  line flag.

		dist:
		  Returns a binary containing a	string of distribution	infor-
		  mation formatted as in Erlang	crash dumps. For more informa-
		  tion,	see section  How to interpret the Erlang  crash	 dumps
		  in the User's	Guide.

		dist_buf_busy_limit:
		  Returns  the	value of the distribution buffer busy limit in
		  bytes. This limit can	be set at startup by passing  command-
		  line flag +zdbbl to erl(1).

		dist_ctrl:
		  Returns  a list of tuples {Node, ControllingEntity}, one en-
		  try for each connected remote	node. Node is  the  node  name
		  and  ControllingEntity is the	port or	process	identifier re-
		  sponsible for	the communication to that node.	More  specifi-
		  cally,  ControllingEntity for	nodes connected	through	TCP/IP
		  (the normal case) is the socket used in  communication  with
		  the specific node.

       erlang:system_info(Item :: build_type) ->
			     opt |
			     debug |
			     purify |
			     quantify |
			     purecov |
			     gcov |
			     valgrind |
			     gprof |
			     lcnt |
			     frmptr

       erlang:system_info(Item :: c_compiler_used) -> {atom(), term()}

       erlang:system_info(Item :: check_io) -> [term()]

       erlang:system_info(Item :: compat_rel) -> integer()

       erlang:system_info(Item :: debug_compiled) -> boolean()

       erlang:system_info(Item :: driver_version) -> string()

       erlang:system_info(Item :: dynamic_trace) ->
			     none | dtrace | systemtap

       erlang:system_info(Item :: dynamic_trace_probes)	-> boolean()

       erlang:system_info(Item :: info)	-> binary()

       erlang:system_info(Item :: kernel_poll) -> boolean()

       erlang:system_info(Item :: loaded) -> binary()

       erlang:system_info(Item :: machine) -> string()

       erlang:system_info(Item :: modified_timing_level) ->
			     integer() | undefined

       erlang:system_info(Item :: nif_version) -> string()

       erlang:system_info(Item :: otp_release) -> string()

       erlang:system_info(Item :: port_parallelism) -> boolean()

       erlang:system_info(Item :: system_architecture) -> string()

       erlang:system_info(Item :: system_logger) ->
			     logger | undefined	| pid()

       erlang:system_info(Item :: system_version) -> string()

       erlang:system_info(Item :: trace_control_word) ->
			     integer() >= 0

       erlang:system_info(Item :: version) -> string()

       erlang:system_info(Item ::
			      wordsize |
			      {wordsize, internal} |
			      {wordsize, external}) ->
			     4 | 8

	      Returns  various information about the current system (emulator)
	      as specified by Item:

		build_type:
		  Returns an atom describing the build	type  of  the  runtime
		  system.  This	 is normally the atom opt for optimized. Other
		  possible return values are debug, purify, quantify, purecov,
		  gcov,	 valgrind, gprof, and lcnt. Possible return values can
		  be added or removed at any time without prior	notice.

		c_compiler_used:
		  Returns a two-tuple describing the C compiler	used when com-
		  piling  the runtime system. The first	element	is an atom de-
		  scribing the name of the compiler, or	undefined if  unknown.
		  The  second  element is a term describing the	version	of the
		  compiler, or undefined if unknown.

		check_io:
		  Returns a list containing  miscellaneous  information	 about
		  the emulators	internal I/O checking. Notice that the content
		  of the returned list can vary	 between  platforms  and  over
		  time.	It is only guaranteed that a list is returned.

		compat_rel:
		  Returns the compatibility mode of the	local node as an inte-
		  ger. The integer returned represents the Erlang/OTP  release
		  that	the  current emulator has been set to be backward com-
		  patible with.	The compatibility mode can  be	configured  at
		  startup by using command-line	flag +R	in erl(1).

		debug_compiled:
		  Returns true if the emulator has been	debug-compiled,	other-
		  wise false.

		driver_version:
		  Returns a string containing the Erlang driver	 version  used
		  by  the runtime system. It has the form  "<major ver>.<minor
		  ver>".

		dynamic_trace:
		  Returns an atom describing the dynamic trace framework  com-
		  piled	into the virtual machine. It can be dtrace, systemtap,
		  or none. For a commercial or standard	build,	it  is	always
		  none.	 The  other return values indicate a custom configura-
		  tion (for example, ./configure --with-dynamic-trace=dtrace).
		  For  more information	about dynamic tracing, see dyntrace(3)
		  manual page and the README.dtrace/README.systemtap files  in
		  the Erlang source code top directory.

		dynamic_trace_probes:
		  Returns  a  boolean()	 indicating  if	 dynamic  trace	probes
		  (dtrace or systemtap)	are built into the emulator. This  can
		  only	be  true  if the virtual machine was built for dynamic
		  tracing (that	is, system_info(dynamic_trace) returns	dtrace
		  or systemtap).

		info:
		  Returns a binary containing a	string of miscellaneous	system
		  information formatted	as in Erlang crash dumps. For more in-
		  formation,  see  section   How to interpret the Erlang crash
		  dumps	in the User's Guide.

		kernel_poll:
		  Returns true if the emulator uses some kind  of  kernel-poll
		  implementation, otherwise false.

		loaded:
		  Returns a binary containing a	string of loaded module	infor-
		  mation formatted as in Erlang	crash dumps. For more informa-
		  tion,	see section How	to interpret the Erlang	crash dumps in
		  the User's Guide.

		machine:
		  Returns a string containing the Erlang machine name.

		modified_timing_level:
		  Returns the modified timing-level (an	integer)  if  modified
		  timing is enabled, otherwise undefined. For more information
		  about	modified timing, see command-line flag +T in erl(1)

		nif_version:
		  Returns a string containing the version of  the  Erlang  NIF
		  interface  used  by  the  runtime  system. It	is on the form
		  "<major ver>.<minor ver>".

		otp_release:

		  Returns a string containing the OTP release  number  of  the
		  OTP release that the currently executing ERTS	application is
		  part of.

		  As from Erlang/OTP 17, the OTP release number	corresponds to
		  the  major OTP version number. No erlang:system_info() argu-
		  ment gives the exact OTP version. This is because the	 exact
		  OTP  version	in the general case is difficult to determine.
		  For more information,	see the	 description  of  versions  in
		  System principles in System Documentation.

		port_parallelism:
		  Returns  the	default	port parallelism scheduling hint used.
		  For more information,	 see  command-line  argument  +spp  in
		  erl(1).

		system_architecture:
		  Returns  a  string containing	the processor and OS architec-
		  ture the emulator is built for.

		system_logger:
		  Returns the current  system_logger  as  set  by  erlang:sys-
		  tem_flag(system_logger, _).

		system_version:
		  Returns  a  string containing	version	number and some	impor-
		  tant properties, such	as the number of schedulers.

		trace_control_word:
		  Returns the value of the node	trace control word.  For  more
		  information, see function get_tcw in section	Match Specifi-
		  cations in Erlang in the User's Guide.

		version:
		  Returns a string containing the version number of the	emula-
		  tor.

		wordsize:
		  Same as {wordsize, internal}.

		{wordsize, internal}:
		  Returns  the	size of	Erlang term words in bytes as an inte-
		  ger, that is,	4 is returned on a 32-bit architecture,	and  8
		  is  returned	on  a  pure 64-bit architecture. On a halfword
		  64-bit emulator, 4 is	returned,  as  the  Erlang  terms  are
		  stored  using	 a  virtual  word size of half the system word
		  size.

		{wordsize, external}:
		  Returns the true word	size of	the  emulator,	that  is,  the
		  size	of  a pointer. The value is given in bytes as an inte-
		  ger. On a pure 32-bit	architecture, 4	is returned. On	both a
		  half word and	on a pure 64-bit architecture, 8 is returned.

       erlang:system_monitor() -> MonSettings

	      Types:

		 MonSettings = undefined | {MonitorPid,	Options}
		 MonitorPid = pid()
		 Options = [system_monitor_option()]
		 system_monitor_option() =
		     busy_port |
		     busy_dist_port |
		     {long_gc, integer() >= 0} |
		     {long_schedule, integer() >= 0} |
		     {large_heap, integer() >= 0}

	      Returns  the  current  system  monitoring	 settings  set	by er-
	      lang:system_monitor/2 as {MonitorPid, Options}, or undefined  if
	      no  settings  exist.  The	 order of the options can be different
	      from the one that	was set.

       erlang:system_monitor(Arg) -> MonSettings

	      Types:

		 Arg = MonSettings = undefined | {MonitorPid, Options}
		 MonitorPid = pid()
		 Options = [system_monitor_option()]
		 system_monitor_option() =
		     busy_port |
		     busy_dist_port |
		     {long_gc, integer() >= 0} |
		     {long_schedule, integer() >= 0} |
		     {large_heap, integer() >= 0}

	      When called with argument	undefined, all system performance mon-
	      itoring settings are cleared.

	      Calling  the  function with {MonitorPid, Options}	as argument is
	      the same as calling erlang:system_monitor(MonitorPid, Options).

	      Returns the previous  system  monitor  settings  just  like  er-
	      lang:system_monitor/0.

       erlang:system_monitor(MonitorPid, Options) -> MonSettings

	      Types:

		 MonitorPid = pid()
		 Options = [system_monitor_option()]
		 MonSettings = undefined | {OldMonitorPid, OldOptions}
		 OldMonitorPid = pid()
		 OldOptions = [system_monitor_option()]
		 system_monitor_option() =
		     busy_port |
		     busy_dist_port |
		     {long_gc, integer() >= 0} |
		     {long_schedule, integer() >= 0} |
		     {large_heap, integer() >= 0}

	      Sets  the	system performance monitoring options. MonitorPid is a
	      local process identifier (pid)  receiving	 system	 monitor  mes-
	      sages. The second	argument is a list of monitoring options:

		{long_gc, Time}:
		  If  a	 garbage  collection in	the system takes at least Time
		  wall clock milliseconds, a message {monitor, GcPid, long_gc,
		  Info}	 is  sent  to  MonitorPid.  GcPid  is the pid that was
		  garbage collected. Info is a list of two-element tuples  de-
		  scribing the result of the garbage collection.

		  One  of the tuples is	{timeout, GcTime}, where GcTime	is the
		  time for the garbage collection in milliseconds.  The	 other
		  tuples   are	 tagged	  with	 heap_size,   heap_block_size,
		  stack_size,	    mbuf_size,	     old_heap_size,	   and
		  old_heap_block_size.	These  tuples are explained in the de-
		  scription  of	 trace	 message   gc_minor_start   (see   er-
		  lang:trace/3). New tuples can	be added, and the order	of the
		  tuples in the	Info list can be changed at any	 time  without
		  prior	notice.

		{long_schedule,	Time}:
		  If a process or port in the system runs uninterrupted	for at
		  least	Time wall clock	milliseconds, a	message	{monitor,  Pi-
		  dOrPort,  long_schedule, Info} is sent to MonitorPid.	PidOr-
		  Port is the process or port that was running.	Info is	a list
		  of two-element tuples	describing the event.

		  If  a	 pid(),	 the tuples {timeout, Millis}, {in, Location},
		  and {out, Location} are present, where Location is either an
		  MFA  ({Module,  Function,  Arity})  describing  the function
		  where	the process was	scheduled in/out, or  the  atom	 unde-
		  fined.

		  If  a	 port(), the tuples {timeout, Millis} and {port_op,Op}
		  are present. Op is one of proc_sig, timeout, input,  output,
		  event,  or  dist_cmd,	depending on which driver callback was
		  executing.

		  proc_sig is an internal operation and	is  never  to  appear,
		  while	 the  others  represent	the corresponding driver call-
		  backs	timeout, ready_input, ready_output, event, and outputv
		  (when	the port is used by distribution). Value Millis	in tu-
		  ple timeout informs about the	uninterrupted  execution  time
		  of  the  process or port, which always is equal to or	higher
		  than the Time	value supplied when starting  the  trace.  New
		  tuples  can  be  added to the	Info list in a future release.
		  The order of the tuples in the list can be  changed  at  any
		  time without prior notice.

		  This	can  be	 used  to detect problems with NIFs or drivers
		  that take too	long to	execute. 1 ms  is  considered  a  good
		  maximum  time	 for  a	 driver	 callback or a NIF. However, a
		  time-sharing system is usually to consider everything	<  100
		  ms as	"possible" and fairly "normal".	However, longer	sched-
		  ule times can	indicate swapping or a misbehaving NIF/driver.
		  Misbehaving NIFs and drivers can cause bad resource utiliza-
		  tion and bad overall system performance.

		{large_heap, Size}:
		  If a garbage collection in the system	results	in  the	 allo-
		  cated	 size  of  a heap being	at least Size words, a message
		  {monitor, GcPid, large_heap, Info} is	 sent  to  MonitorPid.
		  GcPid	 and  Info are the same	as for long_gc earlier,	except
		  that the tuple tagged	with timeout is	not present.

		  The monitor message is sent if the sum of the	sizes  of  all
		  memory  blocks  allocated  for  all heap generations after a
		  garbage collection is	equal to or higher than	Size.

		  When a process is killed by max_heap_size, it	is killed  be-
		  fore	the  garbage  collection is complete and thus no large
		  heap message is sent.

		busy_port:
		  If a process in the system gets suspended because  it	 sends
		  to a busy port, a message {monitor, SusPid, busy_port, Port}
		  is sent to MonitorPid. SusPid	is the pid that	got  suspended
		  when sending to Port.

		busy_dist_port:
		  If  a	 process in the	system gets suspended because it sends
		  to a process on a remote node	whose inter-node communication
		  was  handled	by  a  busy  port, a message {monitor, SusPid,
		  busy_dist_port, Port}	is sent	to MonitorPid. SusPid  is  the
		  pid  that  got suspended when	sending	through	the inter-node
		  communication	port Port.

	      Returns the previous  system  monitor  settings  just  like  er-
	      lang:system_monitor/0.

	  Note:
	      If  a  monitoring	process	gets so	large that it itself starts to
	      cause system monitor messages when garbage collecting, the  mes-
	      sages  enlarge  the  process message queue and probably make the
	      problem worse.

	      Keep the monitoring process neat and do not set the system moni-
	      tor limits too tight.

	      Failures:

		badarg:
		  If MonitorPid	does not exist.

		badarg:
		  If MonitorPid	is not a local process.

       erlang:system_profile() -> ProfilerSettings

	      Types:

		 ProfilerSettings = undefined |	{ProfilerPid, Options}
		 ProfilerPid = pid() | port()
		 Options = [system_profile_option()]
		 system_profile_option() =
		     exclusive |
		     runnable_ports |
		     runnable_procs |
		     scheduler |
		     timestamp |
		     monotonic_timestamp |
		     strict_monotonic_timestamp

	      Returns the current system profiling settings set	by erlang:sys-
	      tem_profile/2 as {ProfilerPid, Options}, or undefined  if	 there
	      are  no settings.	The order of the options can be	different from
	      the one that was set.

       erlang:system_profile(ProfilerPid, Options) -> ProfilerSettings

	      Types:

		 ProfilerPid = pid() | port() |	undefined
		 Options = [system_profile_option()]
		 ProfilerSettings =
		     undefined | {pid()	| port(), [system_profile_option()]}
		 system_profile_option() =
		     exclusive |
		     runnable_ports |
		     runnable_procs |
		     scheduler |
		     timestamp |
		     monotonic_timestamp |
		     strict_monotonic_timestamp

	      Sets system profiler options. ProfilerPid	 is  a	local  process
	      identifier  (pid)	 or port receiving profiling messages. The re-
	      ceiver is	excluded from all profiling. The second	argument is  a
	      list of profiling	options:

		exclusive:
		  If  a	synchronous call to a port from	a process is done, the
		  calling process is considered	not runnable during  the  call
		  runtime  to the port.	The calling process is notified	as in-
		  active, and later active when	the port callback returns.

		monotonic_timestamp:
		  Time stamps in profile messages use Erlang  monotonic	 time.
		  The  time  stamp  (Ts) has the same format and value as pro-
		  duced	by erlang:monotonic_time(nanosecond).

		runnable_procs:
		  If a process is put into or removed from the	run  queue,  a
		  message,  {profile, Pid, State, Mfa, Ts}, is sent to Profil-
		  erPid. Running processes that	are reinserted	into  the  run
		  queue	 after having been pre-empted do not trigger this mes-
		  sage.

		runnable_ports:
		  If a port is put into	or removed from	the run	queue, a  mes-
		  sage,	{profile, Port,	State, 0, Ts}, is sent to ProfilerPid.

		scheduler:
		  If  a	 scheduler is put to sleep or awoken, a	message, {pro-
		  file,	scheduler, Id, State, NoScheds,	Ts}, is	sent  to  Pro-
		  filerPid.

		strict_monotonic_timestamp:
		  Time	stamps in profile messages consist of Erlang monotonic
		  time and a monotonically increasing integer. The time	 stamp
		  (Ts)	has  the  same	format	and  value as produced by {er-
		  lang:monotonic_time(nanosecond),	   erlang:unique_inte-
		  ger([monotonic])}.

		timestamp:
		  Time	stamps	in  profile messages include a time stamp (Ts)
		  that has the same form as returned by	erlang:now(). This  is
		  also	the  default  if  no  time stamp flag is specified. If
		  cpu_timestamp	has been enabled through erlang:trace/3,  this
		  also	effects	 the time stamp	produced in profiling messages
		  when flag timestamp is enabled.

	  Note:
	      erlang:system_profile behavior can change	in a future release.

       erlang:system_time() -> integer()

	      Returns current  Erlang system time in native time unit.

	      Calling  erlang:system_time()  is	 equivalent  to	  erlang:mono-
	      tonic_time() + erlang:time_offset().

	  Note:
	      This  time is not	a monotonically	increasing time	in the general
	      case. For	more information, see the documentation	of  time  warp
	      modes in the User's Guide.

       erlang:system_time(Unit)	-> integer()

	      Types:

		 Unit =	time_unit()

	      Returns  current	 Erlang	 system	 time  converted into the Unit
	      passed as	argument.

	      Calling erlang:system_time(Unit) is  equivalent  to  erlang:con-
	      vert_time_unit(erlang:system_time(), native, Unit).

	  Note:
	      This  time is not	a monotonically	increasing time	in the general
	      case. For	more information, see the documentation	of  time  warp
	      modes in the User's Guide.

       term_to_binary(Term) -> ext_binary()

	      Types:

		 Term =	term()

	      Returns a	binary data object that	is the result of encoding Term
	      according	to the Erlang external term format.

	      This can be used for various purposes, for  example,  writing  a
	      term to a	file in	an efficient way, or sending an	Erlang term to
	      some type	of communications channel not supported	by distributed
	      Erlang.

	      >	Bin = term_to_binary(hello).
	      <<131,100,0,5,104,101,108,108,111>>
	      >	hello =	binary_to_term(Bin).
	      hello

	      See also binary_to_term/1.

	  Note:
	      There  is	 no  guarantee that this function will return the same
	      encoded representation for the same term.

       term_to_binary(Term, Options) ->	ext_binary()

	      Types:

		 Term =	term()
		 Options =
		     [compressed |
		      {compressed, Level :: 0..9} |
		      {minor_version, Version :: 0..2}]

	      Returns a	binary data object that	is the result of encoding Term
	      according	to the Erlang external term format.

	      If  option  compressed  is provided, the external	term format is
	      compressed. The compressed format	is automatically recognized by
	      binary_to_term/1 as from Erlang/OTP R7B.

	      A	 compression  level  can  be  specified	by giving option {com-
	      pressed, Level}. Level is	an integer with	range 0..9, where:

		* 0 - No compression is	done (it is the	same as	giving no com-
		  pressed option).

		* 1  -	Takes  least  time but may not compress	as well	as the
		  higher levels.

		* 6 - Default level when option	compressed is provided.

		* 9 - Takes most time and tries	to produce a  smaller  result.
		  Notice  "tries"  in the preceding sentence; depending	on the
		  input	term, level 9 compression either does or does not pro-
		  duce a smaller result	than level 1 compression.

	      Option  {minor_version, Version} can be used to control some en-
	      coding details. This option was introduced in Erlang/OTP R11B-4.
	      The valid	values for Version are:

		0:
		  Floats  are encoded using a textual representation. This op-
		  tion is useful to ensure  that  releases  before  Erlang/OTP
		  R11B-4 can decode resulting binary.

		  This	version	 encode	 atoms	that  can  be represented by a
		  latin1 string	using latin1 encoding while  only  atoms  that
		  cannot be represented	by latin1 are encoded using utf8.

		1:
		  This	is  as	of  Erlang/OTP 17.0 the	default. It forces any
		  floats in the	term to	be encoded in a	 more  space-efficient
		  and exact way	(namely	in the 64-bit IEEE format, rather than
		  converted to a textual representation). As  from  Erlang/OTP
		  R11B-4, binary_to_term/1 can decode this representation.

		  This	version	 encode	 atoms	that  can  be represented by a
		  latin1 string	using latin1 encoding while  only  atoms  that
		  cannot be represented	by latin1 are encoded using utf8.

		2:
		  Drops	 usage of the latin1 atom encoding and unconditionally
		  use utf8 encoding for	all atoms. This	will be	changed	to the
		  default  in a	future major release of	Erlang/OTP. Erlang/OTP
		  systems as of	R16B can decode	this representation.

	      See also binary_to_term/1.

       throw(Any) -> no_return()

	      Types:

		 Any = term()

	      A	non-local return from a	function. If evaluated within a	catch,
	      catch returns value Any. Example:

	      >	catch throw({hello, there}).
	      {hello,there}

	      Failure: nocatch if not evaluated	within a catch.

       time() -> Time

	      Types:

		 Time =	calendar:time()

	      Returns the current time as {Hour, Minute, Second}.

	      The  time	zone and Daylight Saving Time correction depend	on the
	      underlying OS. Example:

	      >	time().
	      {9,42,44}

       erlang:time_offset() -> integer()

	      Returns the current time offset between  Erlang  monotonic  time
	      and  Erlang system time in native	time unit. Current time	offset
	      added to an Erlang monotonic  time  gives	 corresponding	Erlang
	      system time.

	      The time offset may or may not change during operation depending
	      on the time warp mode used.

	  Note:
	      A	change in time offset can be observed  at  slightly  different
	      points in	time by	different processes.

	      If  the runtime system is	in multi-time warp mode, the time off-
	      set is changed when the runtime system detects that the OS  sys-
	      tem  time	has changed. The runtime system	will, however, not de-
	      tect this	immediately when it occurs. A task checking  the  time
	      offset is	scheduled to execute at	least once a minute; so, under
	      normal operation this is to be detected  within  a  minute,  but
	      during heavy load	it can take longer time.

       erlang:time_offset(Unit)	-> integer()

	      Types:

		 Unit =	time_unit()

	      Returns  the  current time offset	between	 Erlang	monotonic time
	      and  Erlang system time converted	into the Unit passed as	 argu-
	      ment.

	      Same  as	calling	erlang:convert_time_unit(erlang:time_offset(),
	      native, Unit) however optimized for commonly used	Units.

       erlang:timestamp() -> Timestamp

	      Types:

		 Timestamp = timestamp()
		 timestamp() =
		     {MegaSecs :: integer() >= 0,
		      Secs :: integer()	>= 0,
		      MicroSecs	:: integer() >=	0}

	      Returns current  Erlang system time  on  the  format  {MegaSecs,
	      Secs,  MicroSecs}. This format is	the same as os:timestamp/0 and
	      the deprecated erlang:now/0 use. The reason for the existence of
	      erlang:timestamp()  is  purely to	simplify use for existing code
	      that assumes this	time stamp format. Current Erlang system  time
	      can  more	 efficiently  be  retrieved  in	 the time unit of your
	      choice using erlang:system_time/1.

	      The erlang:timestamp() BIF is equivalent to:

	      timestamp() ->
		  ErlangSystemTime = erlang:system_time(microsecond),
		  MegaSecs = ErlangSystemTime div 1000000000000,
		  Secs = ErlangSystemTime div 1000000 -	MegaSecs*1000000,
		  MicroSecs = ErlangSystemTime rem 1000000,
		  {MegaSecs, Secs, MicroSecs}.

	      It, however, uses	a native implementation	that  does  not	 build
	      garbage on the heap and with slightly better performance.

	  Note:
	      This  time is not	a monotonically	increasing time	in the general
	      case. For	more information, see the documentation	of  time  warp
	      modes in the User's Guide.

       tl(List)	-> term()

	      Types:

		 List =	[term(), ...]

	      Returns the tail of List,	that is, the list minus	the first ele-
	      ment, for	example:

	      >	tl([geesties, guilies, beasties]).
	      [guilies,	beasties]

	      Allowed in guard tests.

	      Failure: badarg if List is the empty list	[].

       erlang:trace(PidPortSpec, How, FlagList)	-> integer()

	      Types:

		 PidPortSpec =
		     pid() |
		     port() |
		     all |
		     processes |
		     ports |
		     existing |
		     existing_processes	|
		     existing_ports |
		     new |
		     new_processes |
		     new_ports
		 How = boolean()
		 FlagList = [trace_flag()]
		 trace_flag() =
		     all |
		     send |
		     'receive' |
		     procs |
		     ports |
		     call |
		     arity |
		     return_to |
		     silent |
		     running |
		     exiting |
		     running_procs |
		     running_ports |
		     garbage_collection	|
		     timestamp |
		     cpu_timestamp |
		     monotonic_timestamp |
		     strict_monotonic_timestamp	|
		     set_on_spawn |
		     set_on_first_spawn	|
		     set_on_link |
		     set_on_first_link |
		     {tracer, pid() | port()} |
		     {tracer, module(),	term()}

	      Turns on (if How == true)	or off (if How	==  false)  the	 trace
	      flags  in	 FlagList  for the process or processes	represented by
	      PidPortSpec.

	      PidPortSpec is either a process identifier  (pid)	 for  a	 local
	      process, a port identifier, or one of the	following atoms:

		all:
		  All currently	existing processes and ports and all that will
		  be created in	the future.

		processes:
		  All currently	existing processes and all that	will  be  cre-
		  ated in the future.

		ports:
		  All currently	existing ports and all that will be created in
		  the future.

		existing:
		  All currently	existing processes and ports.

		existing_processes:
		  All currently	existing processes.

		existing_ports:
		  All currently	existing ports.

		new:
		  All processes	and ports that will be created in the future.

		new_processes:
		  All processes	that will be created in	the future.

		new_ports:
		  All ports that will be created in the	future.

	      FlagList can contain any number  of  the	following  flags  (the
	      "message tags" refers to the list	of trace messages):

		all:
		  Sets	all trace flags	except tracer and cpu_timestamp, which
		  are in their nature different	than the others.

		send:
		  Traces sending of messages.

		  Message tags:	send and send_to_non_existing_process.

		'receive':
		  Traces receiving of messages.

		  Message tags:	'receive'.

		call:
		  Traces certain function calls. Specify which function	 calls
		  to trace by calling erlang:trace_pattern/3.

		  Message tags:	call and return_from.

		silent:
		  Used	with  the  call	trace flag. The	call, return_from, and
		  return_to trace messages are inhibited if this flag is  set,
		  but  they are	executed as normal if there are	match specifi-
		  cations.

		  Silent mode is inhibited by executing	erlang:trace(_,	false,
		  [silent|_]), or by a match specification executing the func-
		  tion {silent,	false}.

		  The silent trace flag	facilitates setting up a trace on many
		  or  even  all	processes in the system. The trace can then be
		  activated and	 deactivated  using  the  match	 specification
		  function  {silent,Bool},  giving a high degree of control of
		  which	functions with which arguments that trigger the	trace.

		  Message tags:	call, return_from, and return_to.  Or  rather,
		  the absence of.

		return_to:
		  Used	with  the  call	 trace	flag. Traces the return	from a
		  traced function back to its caller. Only works for functions
		  traced with option local to erlang:trace_pattern/3.

		  The  semantics  is  that a trace message is sent when	a call
		  traced function returns, that	is, when a chain of  tail  re-
		  cursive calls	ends. Only one trace message is	sent per chain
		  of tail recursive calls, so the properties  of  tail	recur-
		  siveness for function	calls are kept while tracing with this
		  flag.	Using call and return_to trace together	makes it  pos-
		  sible	 to  know exactly in which function a process executes
		  at any time.

		  To get trace messages	containing return  values  from	 func-
		  tions, use the {return_trace}	match specification action in-
		  stead.

		  Message tags:	return_to.

		procs:
		  Traces process-related events.

		  Message tags:	spawn, spawned,	 exit,	register,  unregister,
		  link,	unlink,	getting_linked,	and getting_unlinked.

		ports:
		  Traces port-related events.

		  Message  tags:  open,	 closed,  register,  unregister,  get-
		  ting_linked, and getting_unlinked.

		running:
		  Traces scheduling of processes.

		  Message tags:	in and out.

		exiting:
		  Traces scheduling of exiting processes.

		  Message tags:	in_exiting, out_exiting, and out_exited.

		running_procs:
		  Traces scheduling of processes just like  running.  However,
		  this	option	also includes schedule events when the process
		  executes within the context of a port	without	 being	sched-
		  uled out itself.

		  Message tags:	in and out.

		running_ports:
		  Traces scheduling of ports.

		  Message tags:	in and out.

		garbage_collection:
		  Traces garbage collections of	processes.

		  Message  tags:  gc_minor_start, gc_max_heap_size, and	gc_mi-
		  nor_end.

		timestamp:
		  Includes a time stamp	in all trace messages. The time	 stamp
		  (Ts) has the same form as returned by	erlang:now().

		cpu_timestamp:
		  A global trace flag for the Erlang node that makes all trace
		  time stamps using flag timestamp to be in CPU	time, not wall
		  clock	 time.	That is, cpu_timestamp is not be used if mono-
		  tonic_timestamp or  strict_monotonic_timestamp  is  enabled.
		  Only	allowed	 with PidPortSpec==all.	If the host machine OS
		  does not  support  high-resolution  CPU  time	 measurements,
		  trace/3  exits  with badarg. Notice that most	OS do not syn-
		  chronize this	value across cores, so be prepared  that  time
		  can seem to go backwards when	using this option.

		monotonic_timestamp:
		  Includes  an	Erlang	monotonic time time stamp in all trace
		  messages. The	time stamp (Ts)	has the	same format and	 value
		  as  produced by erlang:monotonic_time(nanosecond). This flag
		  overrides flag cpu_timestamp.

		strict_monotonic_timestamp:
		  Includes an time stamp consisting of Erlang  monotonic  time
		  and  a  monotonically	 increasing  integer in	all trace mes-
		  sages. The time stamp	(Ts) has the same format and value  as
		  produced   by	  {   erlang:monotonic_time(nanosecond),   er-
		  lang:unique_integer([monotonic])}. This flag overrides  flag
		  cpu_timestamp.

		arity:
		  Used	with  the  call	trace flag. {M,	F, Arity} is specified
		  instead of {M, F, Args} in call trace	messages.

		set_on_spawn:
		  Makes	any process created by a traced	 process  inherit  its
		  trace	flags, including flag set_on_spawn.

		set_on_first_spawn:
		  Makes	 the first process created by a	traced process inherit
		  its trace flags, excluding flag set_on_first_spawn.

		set_on_link:
		  Makes	any process linked by a	 traced	 process  inherit  its
		  trace	flags, including flag set_on_link.

		set_on_first_link:
		  Makes	 the  first  process linked to by a traced process in-
		  herit	its trace flags, excluding flag	set_on_first_link.

		{tracer, Tracer}:
		  Specifies where to send the trace messages. Tracer  must  be
		  the  process identifier of a local process or	the port iden-
		  tifier of a local port.

		{tracer, TracerModule, TracerState}:
		  Specifies that a tracer module is to be  called  instead  of
		  sending  a  trace message. The tracer	module can then	ignore
		  or change the	trace message. For  more  details  on  how  to
		  write	a tracer module, see erl_tracer(3).

	      If  no tracer is specified, the calling process receives all the
	      trace messages.

	      The effect of combining set_on_first_link	 with  set_on_link  is
	      the  same	 as set_on_first_link alone. Likewise for set_on_spawn
	      and set_on_first_spawn.

	      The tracing process receives the trace messages described	in the
	      following	 list.	Pid  is	 the  process identifier of the	traced
	      process in which the traced event	has occurred. The third	 tuple
	      element is the message tag.

	      If   flag	  timestamp,   strict_monotonic_timestamp,   or	 mono-
	      tonic_timestamp  is  specified,  the  first  tuple  element   is
	      trace_ts	instead,  and the time stamp is	added as an extra ele-
	      ment last	in the message tuple. If multiple time stamp flags are
	      passed,  timestamp  has  precedence  over	strict_monotonic_time-
	      stamp, which in turn has	precedence  over  monotonic_timestamp.
	      All  time	 stamp	flags are remembered, so if two	are passed and
	      the one with highest precedence later is disabled, the other one
	      becomes active.

	      Trace messages:

		{trace,	PidPort, send, Msg, To}:
		  When PidPort sends message Msg to process To.

		{trace,	PidPort, send_to_non_existing_process, Msg, To}:
		  When	PidPort	 sends message Msg to the non-existing process
		  To.

		{trace,	PidPort, 'receive', Msg}:
		  When PidPort receives	message	Msg. If	Msg is	set  to	 time-
		  out,	a receive statement can	have timed out,	or the process
		  received a message with the payload timeout.

		{trace,	Pid, call, {M, F, Args}}:
		  When Pid calls a traced function. The	return values of calls
		  are never supplied, only the call and	its arguments.

		  Trace	 flag arity can	be used	to change the contents of this
		  message, so that Arity is specified instead of Args.

		{trace,	Pid, return_to,	{M, F, Arity}}:
		  When Pid returns to the specified function. This trace  mes-
		  sage	is  sent if both the flags call	and return_to are set,
		  and the function is set  to  be  traced  on  local  function
		  calls.  The message is only sent when	returning from a chain
		  of tail recursive function calls, where at  least  one  call
		  generated a call trace message (that is, the functions match
		  specification	matched, and {message, false} was not  an  ac-
		  tion).

		{trace,	Pid, return_from, {M, F, Arity}, ReturnValue}:
		  When	Pid  returns  from  the	specified function. This trace
		  message is sent if flag call is set, and the function	has  a
		  match	 specification	with a return_trace or exception_trace
		  action.

		{trace,	Pid, exception_from, {M, F, Arity}, {Class, Value}}:
		  When Pid exits from the specified function because of	an ex-
		  ception. This	trace message is sent if flag call is set, and
		  the function	has  a	match  specification  with  an	excep-
		  tion_trace action.

		{trace,	Pid, spawn, Pid2, {M, F, Args}}:
		  When	Pid spawns a new process Pid2 with the specified func-
		  tion call as entry point.

		  Args is supposed to be the argument list,  but  can  be  any
		  term if the spawn is erroneous.

		{trace,	Pid, spawned, Pid2, {M,	F, Args}}:
		  When Pid is spawned by process Pid2 with the specified func-
		  tion call as entry point.

		  Args is supposed to be the argument list,  but  can  be  any
		  term if the spawn is erroneous.

		{trace,	Pid, exit, Reason}:
		  When Pid exits with reason Reason.

		{trace,	PidPort, register, RegName}:
		  When PidPort gets the	name RegName registered.

		{trace,	PidPort, unregister, RegName}:
		  When	PidPort	 gets  the  name RegName unregistered. This is
		  done automatically when a registered process or port exits.

		{trace,	Pid, link, Pid2}:
		  When Pid links to a process Pid2.

		{trace,	Pid, unlink, Pid2}:
		  When Pid removes the link from a process Pid2.

		{trace,	PidPort, getting_linked, Pid2}:
		  When PidPort gets linked to a	process	Pid2.

		{trace,	PidPort, getting_unlinked, Pid2}:
		  When PidPort gets unlinked from a process Pid2.

		{trace,	Pid, exit, Reason}:
		  When Pid exits with reason Reason.

		{trace,	Port, open, Pid, Driver}:
		  When Pid opens a new port Port with the running Driver.

		  Driver is the	name of	the driver as an atom.

		{trace,	Port, closed, Reason}:
		  When Port closes with	Reason.

		{trace,	Pid, in	| in_exiting, {M, F, Arity} | 0}:
		  When Pid is scheduled	to run.	The process runs  in  function
		  {M,  F, Arity}. On some rare occasions, the current function
		  cannot be determined,	then the last element is 0.

		{trace,	Pid, out | out_exiting | out_exited, {M, F,  Arity}  |
		0}:
		  When	Pid is scheduled out. The process was running in func-
		  tion {M, F, Arity}. On  some	rare  occasions,  the  current
		  function cannot be determined, then the last element is 0.

		{trace,	Port, in, Command | 0}:
		  When	Port  is  scheduled to run. Command is the first thing
		  the port will	execute, it can	however	run  several  commands
		  before being scheduled out. On some rare occasions, the cur-
		  rent function	cannot be determined, then the last element is
		  0.

		  The  possible	 commands  are	call, close, command, connect,
		  control, flush, info,	link, open, and	unlink.

		{trace,	Port, out, Command | 0}:
		  When Port is scheduled out. The last command	run  was  Com-
		  mand.	On some	rare occasions,	the current function cannot be
		  determined, then the last element is 0. Command can  contain
		  the same commands as in

		{trace,	Pid, gc_minor_start, Info}:

		  Sent when a young garbage collection is about	to be started.
		  Info is a list of two-element	tuples,	where the  first  ele-
		  ment is a key, and the second	is the value. Do not depend on
		  any order of the tuples. The following keys are defined:

		  heap_size:
		    The	size of	the used part of the heap.

		  heap_block_size:
		    The	size of	the memory block used for storing the heap and
		    the	stack.

		  old_heap_size:
		    The	size of	the used part of the old heap.

		  old_heap_block_size:
		    The	 size  of  the	memory	block used for storing the old
		    heap.

		  stack_size:
		    The	size of	the stack.

		  recent_size:
		    The	size of	the data that survived	the  previous  garbage
		    collection.

		  mbuf_size:
		    The	 combined  size	of message buffers associated with the
		    process.

		  bin_vheap_size:
		    The	total size of unique off-heap binaries referenced from
		    the	process	heap.

		  bin_vheap_block_size:
		    The	 total size of binaries	allowed	in the virtual heap in
		    the	process	before doing a garbage collection.

		  bin_old_vheap_size:
		    The	total size of unique off-heap binaries referenced from
		    the	process	old heap.

		  bin_old_vheap_block_size:
		    The	total size of binaries allowed in the virtual old heap
		    in the process before doing	a garbage collection.

		  All sizes are	in words.

		{trace,	Pid, gc_max_heap_size, Info}:
		  Sent when the	max_heap_size is reached during	 garbage  col-
		  lection.  Info  contains the same kind of list as in message
		  gc_start, but	the sizes reflect  the	sizes  that  triggered
		  max_heap_size	to be reached.

		{trace,	Pid, gc_minor_end, Info}:
		  Sent	when  young  garbage collection	is finished. Info con-
		  tains	the same kind of list as  in  message  gc_minor_start,
		  but  the  sizes  reflect the new sizes after garbage collec-
		  tion.

		{trace,	Pid, gc_major_start, Info}:
		  Sent when  fullsweep	garbage	 collection  is	 about	to  be
		  started.  Info  contains the same kind of list as in message
		  gc_minor_start.

		{trace,	Pid, gc_major_end, Info}:
		  Sent when fullsweep garbage  collection  is  finished.  Info
		  contains the same kind of list as in message gc_minor_start,
		  but the sizes	 reflect  the  new  sizes  after  a  fullsweep
		  garbage collection.

	      If  the  tracing	process/port dies or the tracer	module returns
	      remove, the flags	are silently removed.

	      Each process can only be traced by one  tracer.  Therefore,  at-
	      tempts to	trace an already traced	process	fail.

	      Returns a	number indicating the number of	processes that matched
	      PidPortSpec. If PidPortSpec is a process identifier, the	return
	      value  is	1. If PidPortSpec is all or existing, the return value
	      is the number of processes running. If PidPortSpec is  new,  the
	      return value is 0.

	      Failure:	badarg	if  the	specified arguments are	not supported.
	      For example, cpu_timestamp is not	supported on all platforms.

       erlang:trace_delivered(Tracee) -> Ref

	      Types:

		 Tracee	= pid()	| all
		 Ref = reference()

	      The delivery of trace  messages  (generated  by  erlang:trace/3,
	      seq_trace(3),  or	 erlang:system_profile/2) is dislocated	on the
	      time-line	compared to other events in the	system.	 If  you  know
	      that Tracee has passed some specific point in its	execution, and
	      you want to know when at least all trace messages	 corresponding
	      to  events  up  to  this	point have reached the tracer, use er-
	      lang:trace_delivered(Tracee).

	      When it is guaranteed that all trace messages are	 delivered  to
	      the  tracer  up  to the point that Tracee	reached	at the time of
	      the call to erlang:trace_delivered(Tracee), then a {trace_deliv-
	      ered,  Tracee,  Ref}  message  is	 sent  to  the	caller	of er-
	      lang:trace_delivered(Tracee) .

	      Notice that message trace_delivered does not  imply  that	 trace
	      messages	have been delivered. Instead it	implies	that all trace
	      messages that are	to be delivered	have been delivered. It	is not
	      an  error	 if Tracee is not, and has not been traced by someone,
	      but if this is the case, no trace	messages have  been  delivered
	      when the trace_delivered message arrives.

	      Notice  that  Tracee must	refer to a process currently or	previ-
	      ously  existing  on  the	same  node  as	the  caller   of   er-
	      lang:trace_delivered(Tracee) resides on. The special Tracee atom
	      all denotes all processes	that currently are traced in the node.

	      When used	together with a	 Tracer	Module,	any  message  sent  in
	      the  trace  callback is guaranteed to have reached its recipient
	      before the trace_delivered message is sent.

	      Example: Process A is Tracee, port B is tracer, and process C is
	      the  port	owner of B. C wants to close B when A exits. To	ensure
	      that the trace is	not truncated, C can call  erlang:trace_deliv-
	      ered(A)  when A exits, and wait for message {trace_delivered, A,
	      Ref} before closing B.

	      Failure: badarg if Tracee	does not refer to a process  (dead  or
	      alive)  on  the  same  node as the caller	of erlang:trace_deliv-
	      ered(Tracee) resides on.

       erlang:trace_info(PidPortFuncEvent, Item) -> Res

	      Types:

		 PidPortFuncEvent =
		     pid() |
		     port() |
		     new |
		     new_processes |
		     new_ports |
		     {Module, Function,	Arity} |
		     on_load |
		     send |
		     'receive'
		 Module	= module()
		 Function = atom()
		 Arity = arity()
		 Item =
		     flags |
		     tracer |
		     traced |
		     match_spec	|
		     meta |
		     meta_match_spec |
		     call_count	|
		     call_time |
		     all
		 Res = trace_info_return()
		 trace_info_return() =
		     undefined |
		     {flags, [trace_info_flag()]} |
		     {tracer, pid() | port() | []} |
		     {tracer, module(),	term()}	|
		     trace_info_item_result() |
		     {all, [trace_info_item_result()] |	false |	undefined}
		 trace_info_item_result() =
		     {traced, global | local | false | undefined} |
		     {match_spec, trace_match_spec() | false | undefined} |
		     {meta, pid() | port() | false | undefined | []} |
		     {meta, module(), term()} |
		     {meta_match_spec, trace_match_spec() | false | undefined} |
		     {call_count, integer() >= 0 | boolean() | undefined} |
		     {call_time,
		      [{pid(),
			integer() >= 0,
			integer() >= 0,
			integer() >= 0}] |
		      boolean()	|
		      undefined}
		 trace_info_flag() =
		     send |
		     'receive' |
		     set_on_spawn |
		     call |
		     return_to |
		     procs |
		     set_on_first_spawn	|
		     set_on_link |
		     running |
		     garbage_collection	|
		     timestamp |
		     monotonic_timestamp |
		     strict_monotonic_timestamp	|
		     arity
		 trace_match_spec() =
		     [{[term()]	| '_' |	match_variable(), [term()], [term()]}]
		 match_variable() = atom()
		    Approximation of '$1' | '$2' | '$3'	| ...

	      Returns trace information	about a	port,  process,	 function,  or
	      event.

	      To  get information about	a port or process, PidPortFuncEvent is
	      to be a process identifier (pid),	port identifier, or one	of the
	      atoms new, new_processes,	or new_ports. The atom new or new_pro-
	      cesses means that	the default trace state	for  processes	to  be
	      created  is  returned. The atom new_ports	means that the default
	      trace state for ports to be created is returned.

	      Valid Items for ports and	processes:

		flags:
		  Returns a list of atoms indicating what kind	of  traces  is
		  enabled  for the process. The	list is	empty if no traces are
		  enabled, and one or more of the followings atoms  if	traces
		  are enabled: send, 'receive',	set_on_spawn, call, return_to,
		  procs, ports,	set_on_first_spawn, set_on_link, running, run-
		  ning_procs,  running_ports, silent, exiting, monotonic_time-
		  stamp, strict_monotonic_timestamp, garbage_collection, time-
		  stamp, and arity. The	order is arbitrary.

		tracer:
		  Returns  the	identifier  for	process, port, or a tuple con-
		  taining the tracer module  and  tracer  state	 tracing  this
		  process.  If this process is not traced, the return value is
		  [].

	      To get information about a function, PidPortFuncEvent is	to  be
	      the  three-element  tuple	 {Module, Function, Arity} or the atom
	      on_load. No wildcards are	 allowed.  Returns  undefined  if  the
	      function does not	exist, or false	if the function	is not traced.
	      If PidPortFuncEvent is on_load, the information returned	refers
	      to the default value for code that will be loaded.

	      Valid Items for functions:

		traced:
		  Returns global if this function is traced on global function
		  calls, local if this function	is traced  on  local  function
		  calls	 (that is, local and global function calls), and false
		  if local or global function calls are	not traced.

		match_spec:
		  Returns the match specification for this function, if	it has
		  one.	If  the	function is locally or globally	traced but has
		  no match specification defined, the returned value is	[].

		meta:
		  Returns the meta-trace tracer	process, port, or trace	module
		  for  this  function,	if  it has one.	If the function	is not
		  meta-traced, the returned value is false. If the function is
		  meta-traced but has once detected that the tracer process is
		  invalid, the returned	value is [].

		meta_match_spec:
		  Returns the meta-trace match specification  for  this	 func-
		  tion,	 if it has one.	If the function	is meta-traced but has
		  no match specification defined, the returned value is	[].

		call_count:
		  Returns the call count value for this	function or  true  for
		  the pseudo function on_load if call count tracing is active.
		  Otherwise false is returned.

		  See also erlang:trace_pattern/3.

		call_time:
		  Returns the call time	values for this	function or  true  for
		  the  pseudo function on_load if call time tracing is active.
		  Otherwise false is returned. The call	time values  returned,
		  [{Pid,  Count,  S, Us}], is a	list of	each process that exe-
		  cuted	the function and its specific counters.

		  See also erlang:trace_pattern/3.

		all:
		  Returns a list containing the	{Item, Value} tuples  for  all
		  other	 items,	 or  returns false if no tracing is active for
		  this function.

	      To get information about an event, PidPortFuncEvent is to	be one
	      of the atoms send	or 'receive'.

	      One valid	Item for events	exists:

		match_spec:
		  Returns  the	match  specification for this event, if	it has
		  one, or true if no match specification has been set.

	      The return value is {Item, Value}, where Value is	the  requested
	      information  as  described  earlier. If a	pid for	a dead process
	      was specified, or	the name of a non-existing function, Value  is
	      undefined.

       erlang:trace_pattern(MFA, MatchSpec) -> integer() >= 0

	      Types:

		 MFA = trace_pattern_mfa() | send | 'receive'
		 MatchSpec =
		     (MatchSpecList :: trace_match_spec()) |
		     boolean() |
		     restart |
		     pause
		 trace_pattern_mfa() = {atom(),	atom(),	arity()	| '_'} | on_load
		 trace_match_spec() =
		     [{[term()]	| '_' |	match_variable(), [term()], [term()]}]
		 match_variable() = atom()
		    Approximation of '$1' | '$2' | '$3'	| ...

	      The same as erlang:trace_pattern(Event, MatchSpec, []), retained
	      for backward compatibility.

       erlang:trace_pattern(MFA	:: send, MatchSpec, FlagList ::	[]) ->
			       integer() >= 0

	      Types:

		 MatchSpec = (MatchSpecList :: trace_match_spec()) | boolean()
		 trace_match_spec() =
		     [{[term()]	| '_' |	match_variable(), [term()], [term()]}]
		 match_variable() = atom()
		    Approximation of '$1' | '$2' | '$3'	| ...

	      Sets trace pattern for message sending. Must  be	combined  with
	      erlang:trace/3  to  set the send trace flag for one or more pro-
	      cesses. By default all messages sent from	send traced  processes
	      are  traced.  To	limit  traced send events based	on the message
	      content, the sender and/or the receiver,	use  erlang:trace_pat-
	      tern/3.

	      Argument MatchSpec can take the following	forms:

		MatchSpecList:
		  A  list of match specifications. The matching	is done	on the
		  list [Receiver, Msg].	Receiver is the	process	or port	 iden-
		  tity of the receiver and Msg is the message term. The	pid of
		  the sending process can be accessed with the guard  function
		  self/0. An empty list	is the same as true. For more informa-
		  tion,	see section  Match Specifications  in  Erlang  in  the
		  User's Guide.

		true:
		  Enables tracing for all sent messages	(from send traced pro-
		  cesses). Any match specification is removed. This is the de-
		  fault.

		false:
		  Disables tracing for all sent	messages. Any match specifica-
		  tion is removed.

	      Argument FlagList	must be	[] for send tracing.

	      The return value is always 1.

	      Examples:

	      Only trace messages to a specific	process	Pid:

	      >	erlang:trace_pattern(send, [{[Pid, '_'],[],[]}], []).
	      1

	      Only trace messages matching {reply, _}:

	      >	erlang:trace_pattern(send, [{['_', {reply,'_'}],[],[]}], []).
	      1

	      Only trace messages sent to the sender itself:

	      >	erlang:trace_pattern(send, [{['$1', '_'],[{'=:=','$1',{self}}],[]}], []).
	      1

	      Only trace messages sent to other	nodes:

	      >	erlang:trace_pattern(send, [{['$1', '_'],[{'=/=',{node,'$1'},{node}}],[]}], []).
	      1

	  Note:
	      A	match specification for	send trace can use all guard and  body
	      functions	except caller.

       erlang:trace_pattern(MFA	:: 'receive', MatchSpec, FlagList :: []) ->
			       integer() >= 0

	      Types:

		 MatchSpec = (MatchSpecList :: trace_match_spec()) | boolean()
		 trace_match_spec() =
		     [{[term()]	| '_' |	match_variable(), [term()], [term()]}]
		 match_variable() = atom()
		    Approximation of '$1' | '$2' | '$3'	| ...

	      Sets  trace pattern for message receiving. Must be combined with
	      erlang:trace/3 to	set the	'receive' trace	flag for one  or  more
	      processes.  By default all messages received by 'receive'	traced
	      processes	are traced. To limit traced receive  events  based  on
	      the  message  content,  the  sender and/or the receiver, use er-
	      lang:trace_pattern/3.

	      Argument MatchSpec can take the following	forms:

		MatchSpecList:
		  A list of match specifications. The matching is done on  the
		  list	[Node,	Sender,	 Msg].	Node  is  the node name	of the
		  sender. Sender is  the  process  or  port  identity  of  the
		  sender,  or  the  atom  undefined if the sender is not known
		  (which can be	the case for remote senders). Msg is the  mes-
		  sage	term. The pid of the receiving process can be accessed
		  with the guard function self/0. An empty list	is the same as
		  true.	 For  more  information, see section  Match Specifica-
		  tions	in Erlang in the User's	Guide.

		true:
		  Enables tracing for  all  received  messages	(to  'receive'
		  traced  processes). Any match	specification is removed. This
		  is the default.

		false:
		  Disables tracing for all received messages. Any match	speci-
		  fication is removed.

	      Argument FlagList	must be	[] for receive tracing.

	      The return value is always 1.

	      Examples:

	      Only trace messages from a specific process Pid:

	      >	erlang:trace_pattern('receive',	[{['_',Pid, '_'],[],[]}], []).
	      1

	      Only trace messages matching {reply, _}:

	      >	erlang:trace_pattern('receive',	[{['_','_', {reply,'_'}],[],[]}], []).
	      1

	      Only trace messages from other nodes:

	      >	erlang:trace_pattern('receive',	[{['$1', '_', '_'],[{'=/=','$1',{node}}],[]}], []).
	      1

	  Note:
	      A	 match specification for 'receive' trace can use all guard and
	      body  functions  except  caller,	is_seq_trace,	get_seq_token,
	      set_seq_token,  enable_trace,  disable_trace, trace, silent, and
	      process_dump.

       erlang:trace_pattern(MFA, MatchSpec, FlagList) ->
			       integer() >= 0

	      Types:

		 MFA = trace_pattern_mfa()
		 MatchSpec =
		     (MatchSpecList :: trace_match_spec()) |
		     boolean() |
		     restart |
		     pause
		 FlagList = [trace_pattern_flag()]
		 trace_pattern_mfa() = {atom(),	atom(),	arity()	| '_'} | on_load
		 trace_match_spec() =
		     [{[term()]	| '_' |	match_variable(), [term()], [term()]}]
		 trace_pattern_flag() =
		     global |
		     local |
		     meta |
		     {meta, Pid	:: pid()} |
		     {meta, TracerModule :: module(), TracerState :: term()} |
		     call_count	|
		     call_time
		 match_variable() = atom()
		    Approximation of '$1' | '$2' | '$3'	| ...

	      Enables or disables call tracing for one or more functions. Must
	      be  combined  with erlang:trace/3	to set the call	trace flag for
	      one or more processes.

	      Conceptually, call tracing works as follows. Inside  the	Erlang
	      virtual  machine,	 a set of processes and	a set of functions are
	      to be traced. If a traced	process	calls a	traced	function,  the
	      trace action is taken. Otherwise,	nothing	happens.

	      To add or	remove one or more processes to	the set	of traced pro-
	      cesses, use erlang:trace/3.

	      To add or	remove functions to the	set of traced  functions,  use
	      erlang:trace_pattern/3.

	      The BIF erlang:trace_pattern/3 can also add match	specifications
	      to a function. A match specification comprises  a	 pattern  that
	      the  function arguments must match, a guard expression that must
	      evaluate to true,	and an action to be performed. The default ac-
	      tion  is	to send	a trace	message. If the	pattern	does not match
	      or the guard fails, the action is	not executed.

	      Argument MFA is to be a tuple, such as  {Module,	Function,  Ar-
	      ity},  or	the atom on_load (described below). It can be the mod-
	      ule, function, and arity for a function (or a BIF	 in  any  mod-
	      ule).  The atom '_' can be used as a wildcard in any of the fol-
	      lowing ways:

		{Module,Function,'_'}:
		  All functions	of any arity named Function in module Module.

		{Module,'_','_'}:
		  All functions	in module Module.

		{'_','_','_'}:
		  All functions	in all loaded modules.

	      Other combinations, such as {Module,'_',Arity}, are not allowed.
	      Local  functions	match  wildcards  only	if  option local is in
	      FlagList.

	      If argument MFA is the atom on_load, the match specification and
	      flag list	are used on all	modules	that are newly loaded.

	      Argument MatchSpec can take the following	forms:

		false:
		  Disables tracing for the matching functions. Any match spec-
		  ification is removed.

		true:
		  Enables tracing for the matching functions. Any match	speci-
		  fication is removed.

		MatchSpecList:
		  A  list of match specifications. An empty list is equivalent
		  to true. For a description of	match specifications, see sec-
		  tion	Match Specifications in	Erlang in the User's Guide.

		restart:
		  For  the FlagList options call_count and call_time: restarts
		  the existing counters. The behavior is undefined  for	 other
		  FlagList options.

		pause:
		  For  the  FlagList  options call_count and call_time:	pauses
		  the existing counters. The behavior is undefined  for	 other
		  FlagList options.

	      Parameter	 FlagList  is a	list of	options. The following are the
	      valid options:

		global:
		  Turns	on or off call tracing for global function calls (that
		  is,  calls  specifying the module explicitly). Only exported
		  functions match and only global calls	 generate  trace  mes-
		  sages. This is the default.

		local:
		  Turns	 on  or	 off  call  tracing  for all types of function
		  calls. Trace messages	are sent whenever any of the specified
		  functions  are called, regardless of how they	are called. If
		  flag return_to is set	for the	process, a  return_to  message
		  is also sent when this function returns to its caller.

		meta | {meta, Pid} | {meta, TracerModule, TracerState}:
		  Turns	 on  or	 off  meta-tracing  for	 all types of function
		  calls. Trace messages	are sent to the	tracer whenever	any of
		  the  specified  functions are	called.	If no tracer is	speci-
		  fied,	self() is used as a default tracer process.

		  Meta-tracing traces all processes and	does  not  care	 about
		  the  process	trace  flags  set by erlang:trace/3, the trace
		  flags	are instead fixed to [call, timestamp].

		  The match specification function {return_trace}  works  with
		  meta-trace and sends its trace message to the	same tracer.

		call_count:
		  Starts  (MatchSpec  ==  true)	 or stops (MatchSpec ==	false)
		  call count tracing for all types of function calls. For  ev-
		  ery  function, a counter is incremented when the function is
		  called, in any process. No process trace flags  need	to  be
		  activated.

		  If  call count tracing is started while already running, the
		  count	is restarted from zero.	To pause running counters, use
		  MatchSpec  ==	 pause.	 Paused	 and  running  counters	can be
		  restarted from zero with MatchSpec ==	restart.

		  To read the counter value, use erlang:trace_info/2.

		call_time:
		  Starts (MatchSpec == true) or	 stops	(MatchSpec  ==	false)
		  call time tracing for	all types of function calls. For every
		  function, a counter is  incremented  when  the  function  is
		  called.  Time	 spent	in  the	function is accumulated	in two
		  other	counters, seconds and microseconds. The	 counters  are
		  stored for each call traced process.

		  If  call  time tracing is started while already running, the
		  count	and time restart from zero. To pause running counters,
		  use  MatchSpec  == pause. Paused and running counters	can be
		  restarted from zero with MatchSpec ==	restart.

		  To read the counter value, use erlang:trace_info/2.

	      The options global and local are mutually	exclusive, and	global
	      is  the  default	(if  no	 options  are  specified). The options
	      call_count and meta perform a kind of local tracing, and	cannot
	      be  combined  with global. A function can	be globally or locally
	      traced. If global	tracing	is specified for a set	of  functions,
	      then  local,  meta,  call	 time,	and call count tracing for the
	      matching set of local functions is disabled, and conversely.

	      When disabling trace, the	option must match the  type  of	 trace
	      set  on  the  function.  That is,	local tracing must be disabled
	      with option local	and global tracing with	option global  (or  no
	      option), and so on.

	      Part  of	a match	specification list cannot be changed directly.
	      If a function has	a match	specification, it can be replaced with
	      a	 new  one.  To change an existing match	specification, use the
	      BIF erlang:trace_info/2 to retrieve the existing match  specifi-
	      cation.

	      Returns  the  number of functions	matching argument MFA. This is
	      zero if none matched.

       trunc(Number) ->	integer()

	      Types:

		 Number	= number()

	      Returns an integer by truncating Number, for example:

	      >	trunc(5.5).
	      5

	      Allowed in guard tests.

       tuple_size(Tuple) -> integer() >= 0

	      Types:

		 Tuple = tuple()

	      Returns an integer that is the number of elements	in Tuple,  for
	      example:

	      >	tuple_size({morni, mulle, bwange}).
	      3

	      Allowed in guard tests.

       tuple_to_list(Tuple) -> [term()]

	      Types:

		 Tuple = tuple()

	      Returns a	list corresponding to Tuple. Tuple can contain any Er-
	      lang terms. Example:

	      >	tuple_to_list({share, {'Ericsson_B', 163}}).
	      [share,{'Ericsson_B',163}]

       erlang:unique_integer() -> integer()

	      Generates	and returns an	integer	unique on current runtime sys-
	      tem instance. The	same as	calling	erlang:unique_integer([]).

       erlang:unique_integer(ModifierList) -> integer()

	      Types:

		 ModifierList =	[Modifier]
		 Modifier = positive | monotonic

	      Generates	and returns an	integer	unique on current runtime sys-
	      tem instance. The	integer	is unique in the sense that this  BIF,
	      using  the same set of modifiers,	does not return	the same inte-
	      ger more than once on the	current	runtime	system instance.  Each
	      integer value can	of course be constructed by other means.

	      By default, when [] is passed as ModifierList, both negative and
	      positive integers	can be returned. This to use the range of  in-
	      tegers that do not need heap memory allocation as	much as	possi-
	      ble. By default the returned integers are	also  only  guaranteed
	      to  be  unique,  that is,	any returned integer can be smaller or
	      larger than previously returned integers.

	      Modifiers:

		positive:
		  Returns only positive	integers.

		  Notice that by passing the positive modifier	you  will  get
		  heap allocated integers (bignums) quicker.

		monotonic:
		  Returns   strictly  monotonically increasing integers	corre-
		  sponding to creation time. That is, the integer returned  is
		  always  larger than previously returned integers on the cur-
		  rent runtime system instance.

		  These	values can be used to determine	order  between	events
		  on  the  runtime  system  instance. That is, if both X = er-
		  lang:unique_integer([monotonic]) and Y = erlang:unique_inte-
		  ger([monotonic]) are executed	by different processes (or the
		  same process)	on the same runtime system instance and	X _ Y,
		  we know that X was created before Y.

	    Warning:
		Strictly  monotonically	increasing values are inherently quite
		expensive to generate and scales poorly. This is  because  the
		values	need to	be synchronized	between	CPU cores. That	is, do
		not  pass  the	monotonic  modifier  unless  you  really  need
		strictly monotonically increasing values.

	      All  valid Modifiers can be combined. Repeated (valid) Modifiers
	      in the ModifierList are ignored.

	  Note:
	      The set of integers returned  by	erlang:unique_integer/1	 using
	      different	 sets of Modifiers will	overlap. For example, by call-
	      ing unique_integer([monotonic]),	and  unique_integer([positive,
	      monotonic])  repeatedly,	you  will eventually see some integers
	      that are returned	by both	calls.

	      Failures:

		badarg:
		  if ModifierList is not a proper list.

		badarg:
		  if Modifier is not a valid modifier.

       erlang:universaltime() -> DateTime

	      Types:

		 DateTime = calendar:datetime()

	      Returns the current date and time	according  to  Universal  Time
	      Coordinated  (UTC)  in  the  form	 {{Year,  Month,  Day},	{Hour,
	      Minute, Second}} if supported by the  underlying	OS.  Otherwise
	      erlang:universaltime()  is equivalent to erlang:localtime(). Ex-
	      ample:

	      >	erlang:universaltime().
	      {{1996,11,6},{14,18,43}}

       erlang:universaltime_to_localtime(Universaltime)	-> Localtime

	      Types:

		 Localtime = Universaltime = calendar:datetime()

	      Converts Universal Time Coordinated (UTC)	date and time to local
	      date  and	 time  in the form {{Year, Month, Day},	{Hour, Minute,
	      Second}} if supported by the underlying OS. Otherwise no conver-
	      sion is done, and	Universaltime is returned. Example:

	      >	erlang:universaltime_to_localtime({{1996,11,6},{14,18,43}}).
	      {{1996,11,7},{15,18,43}}

	      Failure:	badarg	if  Universaltime  denotes an invalid date and
	      time.

       unlink(Id) -> true

	      Types:

		 Id = pid() | port()

	      Removes the link,	if there is one, between the  calling  process
	      and the process or port referred to by Id.

	      Returns  true and	does not fail, even if there is	no link	to Id,
	      or if Id does not	exist.

	      Once unlink(Id) has returned, it is guaranteed that the link be-
	      tween  the caller	and the	entity referred	to by Id has no	effect
	      on the caller in the future (unless the link is setup again). If
	      the  caller  is  trapping	exits, an {'EXIT', Id, _} message from
	      the link can have	been placed in the caller's message queue  be-
	      fore the call.

	      Notice that the {'EXIT', Id, _} message can be the result	of the
	      link, but	can also be the	result of Id  calling  exit/2.	There-
	      fore,  it	 can be	appropriate to clean up	the message queue when
	      trapping exits after the call to unlink(Id), as follows:

	      unlink(Id),
	      receive
		  {'EXIT', Id, _} ->
		      true
	      after 0 ->
		      true
	      end

	  Note:
	      Before Erlang/OTP	R11B (ERTS 5.5)	 unlink/1  behaved  completely
	      asynchronously,  that  is, the link was active until the "unlink
	      signal" reached the linked entity. This had an  undesirable  ef-
	      fect, as you could never know when you were guaranteed not to be
	      effected by the link.

	      The current behavior can be viewed as two	 combined  operations:
	      asynchronously  send an "unlink signal" to the linked entity and
	      ignore any future	results	of the link.

       unregister(RegName) -> true

	      Types:

		 RegName = atom()

	      Removes the registered name RegName associated  with  a  process
	      identifier or a port identifier, for example:

	      >	unregister(db).
	      true

	      Users are	advised	not to unregister system processes.

	      Failure: badarg if RegName is not	a registered name.

       whereis(RegName)	-> pid() | port() | undefined

	      Types:

		 RegName = atom()

	      Returns  the process identifier or port identifier with the reg-
	      istered name RegName. Returns undefined if the name is not  reg-
	      istered. Example:

	      >	whereis(db).
	      <0.43.0>

       erlang:yield() -> true

	      Voluntarily  lets	 other processes (if any) get a	chance to exe-
	      cute. Using this function	is similar to receive after  1	-_  ok
	      end, except that yield() is faster.

	  Warning:
	      There  is	seldom or never	any need to use	this BIF as other pro-
	      cesses have a chance to run in another scheduler thread  anyway.
	      Using  this  BIF	without	 a thorough grasp of how the scheduler
	      works can	cause performance degradation.

Ericsson AB			   erts	10.3			     erlang(3)

NAME | DESCRIPTION | DATA TYPES | EXPORTS

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

home | help