Merge branch 'rickard/time_api/master/OTP-11997'

* rickard/time_api/master/OTP-11997: (22 commits)
  Update primary bootstrap
  inets: Suppress deprecated warning on erlang:now/0
  inets: Cleanup of multiple copies of functions Add inets_lib with common functions used by multiple modules
  inets: Update comments
  Suppress deprecated warning on erlang:now/0
  Use new time API and be back-compatible in inets Remove unused functions and removed redundant test
  asn1 test SUITE: Eliminate use of now/0
  Disable deprecated warning on erlang:now/0 in diameter_lib
  Use new time API and be back-compatible in ssh
  Replace all calls to now/0 in CT with new time API functions
  test_server: Replace usage of erlang:now() with usage of new API
  Replace usage of erlang:now() with usage of new API
  Replace usage of erlang:now() with usage of new API
  Replace usage of erlang:now() with usage of new API
  Replace usage of erlang:now() with usage of new API
  otp_SUITE: Warn for calls to erlang:now/0
  Replace usage of erlang:now() with usage of new API
  Multiple timer wheels
  Erlang based BIF timer implementation for scalability
  Implement ethread events with timeout
  ...

1 files changed, 672 insertions, 103 deletions

diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml
index 6daa4b68a8..880c294c73 100644
--- a/erts/doc/src/erlang.xml
+++ b/erts/doc/src/erlang.xml
@@ -58,7 +58,71 @@
     </datatype>
     <datatype>
       <name name="timestamp"></name>
-      <desc><p>See <seealso marker="#now/0">now/0</seealso>.</p>
+      <desc><p>See <seealso marker="#timestamp/0">erlang:timestamp/0</seealso>.</p>
+      </desc>
+    </datatype>
+    <marker id="type_time_unit"/>
+    <datatype>
+      <name name="time_unit"></name>
+      <desc><p>Currently supported time unit representations:</p>
+        <taglist>
+	  <tag><c>PartsPerSecond :: integer() >= 1</c></tag>
+	  <item><p>Time unit expressed in parts per second. That is,
+	  the time unit equals <c>1/PartsPerSecond</c> second.</p></item>
+
+	  <tag><c>seconds</c></tag>
+	  <item><p>Symbolic representation of the time unit
+	  represented by the integer <c>1</c>.</p></item>
+
+	  <tag><c>milli_seconds</c></tag>
+	  <item><p>Symbolic representation of the time unit
+	  represented by the integer <c>1000</c>.</p></item>
+
+	  <tag><c>micro_seconds</c></tag>
+	  <item><p>Symbolic representation of the time unit
+	  represented by the integer <c>1000000</c>.</p></item>
+
+	  <tag><c>nano_seconds</c></tag>
+	  <item><p>Symbolic representation of the time unit
+	  represented by the integer <c>1000000000</c>.</p></item>
+
+	  <tag><c>native</c></tag>
+	  <item><p>Symbolic representation of the native time unit
+	  used by the Erlang runtime system.</p>
+
+	  <p>The <c>native</c> time unit is determined at
+	  runtime system start, and will remain the same until
+	  the runtime system terminates. If a runtime system
+	  is stopped and then started again (even on the same
+	  machine), the <c>native</c> time unit of the new
+	  runtime system instance may differ from the
+	  <c>native</c> time unit of the old runtime system
+	  instance.</p>
+
+	  <p>One can get an approximation of the <c>native</c>
+	  time unit by calling <c>erlang:convert_time_unit(1,
+	  seconds, native)</c>. The result equals the number
+	  of whole <c>native</c> time units per second. In case
+	  the number of <c>native</c> time units per second does
+	  not add up to a whole number, the result will be
+	  rounded downwards.</p>
+
+	  <note>
+	    <p>The value of the <c>native</c> time unit gives
+	    you more or less no information at all about the
+	    quality of time values. It sets an upper bound for
+	    the resolution as well as for the precision, but it
+	    gives absolutely no information at all about the
+	    accuracy.</p>
+	  </note>
+	  </item>
+
+	</taglist>
+
+	<p>The <c>time_unit/0</c> type may be extended. Use
+	<seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit/3</c></seealso>
+	in order to convert time values between time units.</p>
+
       </desc>
     </datatype>
   </datatypes>
@@ -585,6 +649,22 @@
       </desc>
     </func>
     <func>
+      <name name="convert_time_unit" arity="3"/>
+      <fsummary>Convert time unit of a time value</fsummary>
+      <desc>
+	<p>Converts the <c><anno>Time</anno></c> value of time unit
+	<c><anno>FromUnit</anno></c> to the corresponding
+	<c><anno>ConvertedTime</anno></c> value of time unit
+	<c><anno>ToUnit</anno></c>. The result is rounded
+	using the floor function.</p>
+
+	<warning><p>You may lose accuracy and precision when converting
+	between	time units. In order to minimize such loss, collect all
+	data at <c>native</c> time unit and do the conversion on the end
+	result.</p></warning>
+      </desc>
+    </func>
+    <func>
       <name name="crc32" arity="1"/>
       <fsummary>Compute crc32 (IEEE 802.3) checksum</fsummary>
       <desc>
@@ -2205,14 +2285,15 @@ os_prompt% </pre>
     </func>
     <func>
       <name name="make_ref" arity="0"/>
-      <fsummary>Return an almost unique reference</fsummary>
+      <fsummary>Return a unique reference</fsummary>
       <desc>
-        <p>Returns an almost unique reference.</p>
-        <p>The returned reference will re-occur after approximately 2^82
-          calls; therefore it is unique enough for practical purposes.</p>
-        <pre>
-> <input>make_ref().</input>
-#Ref&lt;0.0.0.135></pre>
+	<p>Return a <seealso marker="doc/efficiency_guide:advanced#unique_references">unique
+	reference</seealso>. The reference is unique among
+	connected nodes.</p>
+	<warning><p>Known issue: When a node is restarted multiple
+	times with the same node name, references created
+	on a newer node can be mistaken for a reference
+	created on an older node with the same node name.</p></warning>
       </desc>
     </func>
     <func>
@@ -2513,97 +2594,178 @@ os_prompt% </pre>
       </desc>
     </func>
     <func>
-      <name name="monitor" arity="2"/>
+      <name name="monitor" arity="2" clause_i="1"/>
+      <name name="monitor" arity="2" clause_i="2"/>
+      <type name="registered_name"/>
+      <type name="registered_process_identifier"/>
+      <type name="monitor_process_identifier"/>
       <fsummary>Start monitoring</fsummary>
       <desc>
-        <p>The calling process starts monitoring <c><anno>Item</anno></c> which is
-          an object of type <c><anno>Type</anno></c>.</p>
-        <p>Currently only processes can be monitored, i.e. the only
-          allowed <c><anno>Type</anno></c> is <c>process</c>, but other types may be
-          allowed in the future.</p>
-        <p><c><anno>Item</anno></c> can be:</p>
-        <taglist>
-          <tag><c>pid()</c></tag>
-          <item>
-            <p>The pid of the process to monitor.</p>
-          </item>
-          <tag><c>{RegName, Node}</c></tag>
-          <item>
-            <p>A tuple consisting of a registered name of a process and
-              a node name. The process residing on the node <c>Node</c>
-              with the registered name <c>RegName</c> will be monitored.</p>
-          </item>
-          <tag><c>RegName</c></tag>
-          <item>
-            <p>The process locally registered as <c>RegName</c> will be
-              monitored.</p>
-          </item>
-        </taglist>
-        <note>
-          <p>When a process is monitored by registered name, the process
-            that has the registered name at the time when
-            <c>monitor/2</c> is called will be monitored.
+	<p>Send a monitor request of type <c><anno>Type</anno></c> to the
+	entity identified by <c><anno>Item</anno></c>. The caller of
+	<c>monitor/2</c> will later be notified by a monitor message on the
+	following format if the monitored state is changed:</p>
+        <code type="none">{Tag, <anno>MonitorRef</anno>, <anno>Type</anno>, Object, Info}</code>
+	<note><p>The monitor request is an asynchronous signal. That is, it
+	takes time before the signal reach its destination.</p></note>
+	<p>Currently valid <c><anno>Type</anno></c>s:</p>
+	<taglist>
+	  <tag><marker id="monitor_process"/><c>process</c></tag>
+	  <item>
+	    <p>Monitor the existence of the process identified by
+	    <c><anno>Item</anno></c>. Currently valid
+	    <c><anno>Item</anno></c>s in combination with the
+	    <c>process <anno>Type</anno></c>:</p>
+            <taglist>
+              <tag><c>pid()</c></tag>
+              <item>
+		<p>The process identifier of the process to monitor.</p>
+              </item>
+              <tag><c>{RegisteredName, Node}</c></tag>
+              <item>
+		<p>A tuple consisting of a registered name of a process and
+		a node name. The process residing on the node <c>Node</c>
+		with the registered name <c>{RegisteredName, Node}</c> will
+		be monitored.</p>
+              </item>
+              <tag><c>RegisteredName</c></tag>
+              <item>
+		<p>The process locally registered as <c>RegisteredName</c>
+		will become monitored.</p>
+              </item>
+            </taglist>
+            <note><p>When a process is monitored by registered name, the
+	    process that has the registered name at the time when the
+            monitor request reach its destination will be monitored.
             The monitor will not be effected, if the registered name is
-            unregistered.</p>
-        </note>
-        <p>A <c>'DOWN'</c> message will be sent to the monitoring
-          process if <c><anno>Item</anno></c> dies, if <c><anno>Item</anno></c> does not exist,
-          or if the connection is lost to the node which <c><anno>Item</anno></c>
-          resides on. A <c>'DOWN'</c> message has the following pattern:</p>
-        <code type="none">
-{'DOWN', MonitorRef, Type, Object, Info}</code>
-        <p>where <c>MonitorRef</c> and <c>Type</c> are the same as
-          described above, and:</p>
-        <taglist>
-          <tag><c>Object</c></tag>
-          <item>
-            <p>A reference to the monitored object:</p>
-            <list type="bulleted">
-              <item>the pid of the monitored process, if <c><anno>Item</anno></c> was
-               specified as a pid.</item>
-              <item><c>{RegName, Node}</c>, if <c><anno>Item</anno></c> was specified as
-              <c>{RegName, Node}</c>.</item>
-              <item><c>{RegName, Node}</c>, if <c><anno>Item</anno></c> was specified as
-              <c>RegName</c>. <c>Node</c> will in this case be the
-               name of the local node (<c>node()</c>).</item>
-            </list>
-          </item>
-          <tag><c>Info</c></tag>
-          <item>
-            <p>Either the exit reason of the process, <c>noproc</c>
-              (non-existing process), or <c>noconnection</c> (no
-              connection to <c><anno>Node</anno></c>).</p>
-          </item>
-        </taglist>
-        <note>
-          <p>If/when <c>monitor/2</c> is extended (e.g. to
-            handle other item types than <c>process</c>), other
-            possible values for <c>Object</c>, and <c>Info</c> in the
-            <c>'DOWN'</c> message will be introduced.</p>
-        </note>
-        <p>The monitoring is turned off either when the <c>'DOWN'</c>
-          message is sent, or when
-          <seealso marker="#demonitor/1">demonitor/1</seealso>
-          is called.</p>
-        <p>If an attempt is made to monitor a process on an older node
-          (where remote process monitoring is not implemented or one
-          where remote process monitoring by registered name is not
-          implemented), the call fails with <c>badarg</c>.</p>
-        <p>Making several calls to <c>monitor/2</c> for the same
-          <c><anno>Item</anno></c> is not an error; it results in as many, completely
-          independent, monitorings.</p>
+            unregistered, or unregistered and later registered on another
+	    process.</p></note>
+	    <p>The monitor is triggered either when the monitored process
+	    terminates, is non existing, or if the connection to it is
+	    lost. In the case the connection to it is lost, we do not know
+	    if it still exist or not. After this type of monitor has been
+	    triggered, the monitor is automatically removed.</p>
+            <p>When the monitor is triggered a <c>'DOWN'</c> message will
+	    be sent to the monitoring process. A <c>'DOWN'</c> message has
+	    the following pattern:</p>
+            <code type="none">{'DOWN', MonitorRef, Type, Object, Info}</code>
+            <p>where <c>MonitorRef</c> and <c>Type</c> are the same as
+            described above, and:</p>
+            <taglist>
+              <tag><c>Object</c></tag>
+              <item>
+		<p>equals:</p>
+		<taglist>
+		  <tag><c><anno>Item</anno></c></tag>
+		  <item>If <c><anno>Item</anno></c> was specified by a
+		  pid.</item>
+		  <tag><c>{RegisteredName, Node}</c></tag>
+		  <item>If <c><anno>Item</anno></c> was specified as
+		  <c>RegisteredName</c>, or <c>{RegisteredName, Node}</c>
+		  where <c>Node</c> corresponds to the node that the
+		  monitored process resides on.</item>
+		</taglist>
+              </item>
+              <tag><c>Info</c></tag>
+              <item>
+		<p>Either the exit reason of the process, <c>noproc</c>
+		(non-existing process), or <c>noconnection</c> (no
+		connection to the node where the monitored process
+		resides).</p></item>
+	    </taglist>
+	    <p>The monitoring is turned off either when the <c>'DOWN'</c>
+	    message is sent, or when
+	    <seealso marker="#demonitor/1">demonitor/1</seealso>
+	    is called.</p>
+	    <p>If an attempt is made to monitor a process on an older node
+	    (where remote process monitoring is not implemented or one
+	    where remote process monitoring by registered name is not
+	    implemented), the call fails with <c>badarg</c>.</p>
+	    <note>
+	      <p>The format of the <c>'DOWN'</c> message changed in the 5.2
+	      version of the emulator (OTP release R9B) for monitor
+	      <em>by registered name</em>. The <c>Object</c> element of
+	      the <c>'DOWN'</c> message could in earlier versions
+	      sometimes be the pid of the monitored process and sometimes
+	      be the registered name. Now the <c>Object</c> element is
+	      always a tuple consisting of the registered name and
+	      the node name. Processes on new nodes (emulator version 5.2
+	      or greater) will always get <c>'DOWN'</c> messages on
+	      the new format even if they are monitoring processes on old
+	      nodes. Processes on old nodes will always get <c>'DOWN'</c>
+	      messages on the old format.</p>
+	    </note>
+	  </item>
+	  <tag><marker id="monitor_time_offset"/><c>time_offset</c></tag>
+	  <item>
+	    <p>Monitor changes in
+	    <seealso marker="#time_offset/0">time offset</seealso>
+	    between
+	    <seealso marker="time_correction#Erlang_Monotonic_Time">Erlang
+	    monotonic time</seealso> and
+	    <seealso marker="time_correction#Erlang_System_Time">Erlang
+	    system time</seealso>. There is only one valid
+	    <c><anno>Item</anno></c> in combination with the
+	    <c>time_offset <anno>Type</anno></c>, namely the atom
+	    <c>clock_service</c>. Note that the atom <c>clock_service</c> is
+	    <em>not</em> the registered name of a process. In this specific
+	    case it serves as an identifier of the runtime system internal
+	    clock service at current runtime system instance.</p>
+
+	    <p>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
+	    <seealso marker="#system_flag_time_offset">finalization
+	    of the time offset</seealso> when the
+	    <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	    time warp mode</seealso> is used. When a change from preliminary
+	    to final time offset is made, the monitor will be triggered once
+	    regardless of whether the time offset value was changed due to
+	    the finalization or not.</p>
+
+	    <p>If the runtime system is in
+	    <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	    time warp mode</seealso>, the time offset will be changed when
+	    the runtime system detects that the
+	    <seealso marker="time_correction#OS_System_Time">OS system
+	    time</seealso> has changed. The runtime system will, however,
+	    not detect this immediately when it happens. A task checking
+	    the time offset is scheduled to execute at least once a minute,
+	    so under normal operation this should be detected within a
+	    minute, but during heavy load it might take longer time.</p>
+
+	    <p>The monitor will <em>not</em> be automatically removed
+	    after it has been triggered. That is, repeated changes of
+	    the time offset will trigger the monitor repeatedly.</p>
+
+            <p>When the monitor is triggered a <c>'CHANGE'</c> message will
+	    be sent to the monitoring process. A <c>'CHANGE'</c> message has
+	    the following pattern:</p>
+            <code type="none">{'CHANGE', MonitorRef, Type, Item, NewTimeOffset}</code>
+            <p>where <c>MonitorRef</c>, <c><anno>Type</anno></c>, and 
+	    <c><anno>Item</anno></c> are the same as described above, and
+	    <c>NewTimeOffset</c> is the new time offset.</p>
+
+	    <p>When the <c>'CHANGE'</c> message has been received you are
+	    guaranteed not to retrieve the old time offset when calling
+	    <seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso>.
+	    Note that you may observe the change of the time offset
+	    when calling <c>erlang:time_offset()</c> before you
+	    get the <c>'CHANGE'</c> message.</p>
+
+	  </item>
+	</taglist>
+	<p>Making several calls to <c>monitor/2</c> for the same
+	<c><anno>Item</anno></c> and/or <c><anno>Type</anno></c> is not
+	an error; it results in many, completely independent,
+	monitorings.</p>
+	<p>The monitor functionality is expected to be extended. That is,
+	other <c><anno>Type</anno></c>s and <c><anno>Item</anno></c>s
+	are expected to be supported in	the future.</p>
         <note>
-          <p>The format of the <c>'DOWN'</c> message changed in the 5.2
-            version of the emulator (OTP release R9B) for monitor <em>by registered name</em>. The <c>Object</c> element of
-            the <c>'DOWN'</c> message could in earlier versions
-            sometimes be the pid of the monitored process and sometimes
-            be the registered name. Now the <c>Object</c> element is
-            always a tuple consisting of the registered name and
-            the node name. Processes on new nodes (emulator version 5.2
-            or greater) will always get <c>'DOWN'</c> messages on
-            the new format even if they are monitoring processes on old
-            nodes. Processes on old nodes will always get <c>'DOWN'</c>
-            messages on the old format.</p>
+          <p>If/when <c>monitor/2</c> is extended, other
+            possible values for <c>Tag</c>, <c>Object</c>, and
+	    <c>Info</c> in the monitor message will be introduced.</p>
         </note>
       </desc>
     </func>
@@ -2654,6 +2816,51 @@ os_prompt% </pre>
       </desc>
     </func>
     <func>
+      <name name="monotonic_time" arity="0"/>
+      <fsummary>Current Erlang monotonic time</fsummary>
+      <desc>
+	<p>Returns the current
+	<seealso marker="time_correction#Erlang_Monotonic_Time">Erlang
+	monotonic time</seealso> in <c>native</c>
+	<seealso marker="#type_time_unit">time unit</seealso>. This
+	is a monotonically increasing time since some unspecified point in
+	time.</p>
+
+	<note><p>This is a
+	<seealso marker="time_correction#Monotonically_Increasing">monotonically increasing</seealso> time, but <em>not</em> a
+	<seealso marker="time_correction#Strictly_Monotonically_Increasing">strictly monotonically increasing</seealso>
+	time. That is, consecutive calls to
+	<c>erlang:monotonic_time/0</c> may produce the same result.</p>
+
+	<p>Different runtime system instances will use different
+	unspecified points in time as base for their Erlang monotonic clocks.
+	That is, it is <em>pointless</em> comparing monotonic times from
+	different runtime system instances. Different runtime system instances
+	may also place this unspecified point in time different relative
+	runtime system start. It may be placed in the future (time at start
+	will be a negative value), the past (time at start will be a
+	positive value), or the runtime system start (time at start will
+	be zero). The monotonic time as of runtime system start can be
+	retrieved by calling
+	<seealso marker="#system_info_start_time"><c>erlang:system_info(start_time)</c></seealso>.</p></note>
+      </desc>
+    </func>
+    <func>
+      <name name="monotonic_time" arity="1"/>
+      <fsummary>Current Erlang monotonic time</fsummary>
+      <desc>
+	<p>Returns the current
+	<seealso marker="time_correction#Erlang_Monotonic_Time">Erlang
+	monotonic time</seealso> converted
+	into the <c><anno>Unit</anno></c> passed as argument.</p>
+
+	<p>Same as calling
+	<seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#monotonic_time/0"><c>erlang:monotonic_time()</c></seealso><c>,
+	native, <anno>Unit</anno>)</c>
+	however optimized for commonly used <c><anno>Unit</anno></c>s.</p>
+      </desc>
+    </func>
+    <func>
       <name name="nif_error" arity="1"/>
       <fsummary>Stop execution with a given reason</fsummary>
       <desc>
@@ -2748,6 +2955,13 @@ os_prompt% </pre>
       <type name="timestamp"/>
       <fsummary>Elapsed time since 00:00 GMT</fsummary>
       <desc>
+	<warning><p><em>This function is deprecated! Do not use it!</em>
+	See the users guide chapter
+	<seealso marker="time_correction">Time and Time Correction</seealso>
+	for more information. Specifically the 
+	<seealso marker="time_correction#Dos_and_Donts">Dos and Dont's</seealso>
+	section for information on what to use instead of <c>erlang:now/0</c>.
+	</p></warning>
         <p>Returns the tuple <c>{MegaSecs, Secs, MicroSecs}</c> which is
           the elapsed time since 00:00 GMT, January 1, 1970 (zero hour)
           on the assumption that the underlying OS supports this.
@@ -2760,10 +2974,6 @@ os_prompt% </pre>
         <p>It can only be used to check the local time of day if
           the time-zone info of the underlying operating system is
           properly configured.</p>
-        <p>If you do not need the return value to be unique and
-          monotonically increasing, use
-          <seealso marker="kernel:os#timestamp/0">os:timestamp/0</seealso>
-          instead to avoid some overhead.</p>
       </desc>
     </func>
     <func>
@@ -5510,6 +5720,35 @@ ok
         <p>Returns the old value of the flag.</p>
       </desc>
     </func>
+    <marker id="system_flag_time_offset"/>
+    <func>
+      <name name="system_flag" arity="2" clause_i="12"/>
+      <fsummary>Finalize the Time Offset</fsummary>
+      <desc>
+        <p>Finalizes the <seealso marker="#time_offset/0">time offset</seealso>
+	when the <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	time warp mode</seealso> is being used. If another time warp mode than
+	the "single time warp mode" is used, the time offset state will be left
+	unchanged.</p>
+        <p>Returns the old state identifier. That is, if:</p>
+	<list>
+	  <item><p><c>preliminary</c> is returned, finalization was
+	  performed and the time offset is now final.</p></item>
+
+	  <item><p><c>final</c> is returned, the time offset was
+	  already in the final state. This either due to another
+	  <c>erlang:system_flag(time_offset, finalize)</c> call, or
+	  due to the
+	  <seealso marker="time_correction#No_Time_Warp_Mode">no
+	  time warp mode</seealso> being used.</p></item>
+
+	  <item><p><c>volatile</c> is returned, the time offset
+	  cannot be finalized due to the 
+	  <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	  time warp mode</seealso> being used.</p></item>
+	</list>
+      </desc>
+    </func>
     <func>
       <name name="system_info" arity="1" clause_i="1"/>
       <name name="system_info" arity="1" clause_i="2"/>
@@ -5790,6 +6029,15 @@ ok
       <name name="system_info" arity="1" clause_i="53"/>
       <name name="system_info" arity="1" clause_i="54"/>
       <name name="system_info" arity="1" clause_i="55"/>
+      <name name="system_info" arity="1" clause_i="56"/>
+      <name name="system_info" arity="1" clause_i="57"/>
+      <name name="system_info" arity="1" clause_i="58"/>
+      <name name="system_info" arity="1" clause_i="59"/>
+      <name name="system_info" arity="1" clause_i="60"/>
+      <name name="system_info" arity="1" clause_i="61"/>
+      <name name="system_info" arity="1" clause_i="62"/>
+      <name name="system_info" arity="1" clause_i="63"/>
+      <name name="system_info" arity="1" clause_i="64"/>
       <fsummary>Information about the system</fsummary>
       <desc>
         <p>Returns various information about the current system
@@ -6177,6 +6425,57 @@ ok
 	    documentation of versions in the system principles
 	    guide</seealso>.</p>
           </item>
+          <tag><marker id="system_info_os_monotonic_time_source"><c>os_monotonic_time_source</c></marker></tag>
+          <item>
+            <p>Returns a list containing information about the source of
+	    <seealso marker="erts:time_correction#OS_Monotonic_Time">OS
+	    monotonic time</seealso> that is used by the runtime system.</p>
+	    <p>In case <c>[]</c> is returned, no OS monotonic time is
+	    available. The list contains two-tuples with <c>Key</c>s
+	    as first element, and <c>Value</c>s as second element. The
+	    order if these tuples is undefined. Currently the following
+	    tuples may be part of the list, but more tuples may be
+	    introduced in the future:</p>
+	    <taglist>
+	      <tag><c>{function, Function}</c></tag>
+	      <item><p><c>Function</c> is the name of the funcion
+	      used. This tuple always exist if OS monotonic time is
+	      available to the runtime system.</p></item>
+
+	      <tag><c>{clock_id, ClockId}</c></tag>
+	      <item><p>This tuple only exist if <c>Function</c>
+	      can be used with different clocks. <c>ClockId</c>
+	      corresponds to the clock identifer used when calling
+	      <c>Function</c>.</p></item>
+
+	      <tag><c>{resolution, OsMonotonicTimeResolution}</c></tag>
+	      <item><p>Highest possible resolution of current
+	      OS monotonic time source as parts per second. If
+	      no resolution information can be retreived from
+	      the OS, <c>OsMonotonicTimeResolution</c> will be
+	      set to the resolution of the time unit of
+	      <c>Function</c>s return value. That is, the actual
+	      resolution may be lower than
+	      <c>OsMonotonicTimeResolution</c>. Also note that
+	      the resolution does not say anything about the
+	      accuracy, and that the precision might not align
+	      with the resolution. You do, however, know that the
+	      precision won't be higher than
+	      <c>OsMonotonicTimeResolution</c>.</p></item>
+
+	      <tag><c>{parallel, Parallel}</c></tag>
+	      <item><p><c>Parallel</c> equals <c>yes</c> if
+	      <c>Function</c> is called in parallel from multiple
+	      threads. If it is not called in parallel, because
+	      calls needs to be serialized, <c>Parallel</c> equals
+	      <c>no</c>.</p></item>
+
+	      <tag><c>{time, OsMonotonicTime}</c></tag>
+	      <item><p><c>OsMonotonicTime</c> equals current OS
+	      monotonic time in <c>native</c>
+	      <seealso marker="#type_time_unit">time unit</seealso>.</p></item>
+	    </taglist>
+          </item>
 	  <tag><marker id="system_info_port_parallelism"><c>port_parallelism</c></marker></tag>
 	  <item><p>Returns the default port parallelism scheduling hint used.
 	  For more information see the
@@ -6302,6 +6601,11 @@ ok
             <p>Returns <c>true</c> if the emulator has been compiled
               with smp support; otherwise, <c>false</c>.</p>
           </item>
+	  <tag><marker id="system_info_start_time"/><c>start_time</c></tag>
+	  <item><p>The <seealso marker="#monotonic_time/0">Erlang monotonic
+	  time</seealso> in <c>native</c>
+	  <seealso marker="#type_time_unit">time unit</seealso> at the
+	  time when current Erlang runtime system instance started.</p></item>
           <tag><c>system_version</c></tag>
           <item>
             <p>Returns a string containing version number and
@@ -6325,12 +6629,64 @@ ok
               (<seealso marker="erts:erl_driver#driver_async">driver_async()</seealso>)
               as an integer.</p>
           </item>
+	  <tag><marker id="system_info_time_correction"/><c>time_correction</c></tag>
+	  <item><p>Returns a boolean value indicating whether
+	  <seealso marker="time_correction#Time_Correction">time correction</seealso>
+	  is enabled or not.
+	  </p></item>
+	  <tag><marker id="system_info_time_offset"/><c>time_offset</c></tag>
+	  <item><p>Returns the state of the time offset:</p>
+	  <taglist>
+	    <tag><c>preliminary</c></tag>
+	    <item><p>The time offset is preliminary, and will be changed
+	    at a later time when being finalized. The preliminary time offset
+	    is used during the preliminary phase of the
+	    <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	    time warp mode</seealso>.</p></item>
+
+	    <tag><c>final</c></tag>
+	    <item><p>The time offset is final. This
+	    either due to the use of the
+	    <seealso marker="time_correction#No_Time_Warp_Mode">no
+	    time warp mode</seealso>, or due to the time offset having
+	    been finalized when using the
+	    <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	    time warp mode</seealso>.</p></item>
+
+	    <tag><c>volatile</c></tag>
+	    <item><p>The time offset is volatile. That is, it may
+	    change at any time. This due to the
+	    <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	    time warp mode</seealso> being used.</p></item>
+	  </taglist>
+	  </item>
+	  <tag><marker id="system_info_time_warp_mode"/><c>time_warp_mode</c></tag>
+	  <item><p>Returns a value identifying the
+	  <seealso marker="time_correction#Time_Warp_Modes">time warp
+	  mode</seealso> being used:</p>
+	  <taglist>
+	    <tag><c>no_time_warp</c></tag>
+	    <item><p>The <seealso marker="time_correction#No_Time_Warp_Mode">no
+	    time warp mode</seealso> is being used.</p></item>
+
+	    <tag><c>single_time_warp</c></tag>
+	    <item><p>The <seealso marker="time_correction#Single_Time_Warp_Mode">single
+	    time warp mode</seealso> is being used.</p></item>
+
+	    <tag><c>multi_time_warp</c></tag>
+	    <item><p>The <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	    time warp mode</seealso> is being used.</p></item>
+	  </taglist>
+	  </item>
           <tag><marker id="system_info_tolerant_timeofday"><c>tolerant_timeofday</c></marker></tag>
           <item>
-            <p>Returns whether compensation for sudden changes of system
-              time is <c>enabled</c> or <c>disabled</c>.</p>
-            <p>See also <seealso marker="erts:erl#+c">+c</seealso>
-              command line flag.</p>
+            <p>Returns whether a pre erts-7.0 backwards compatible compensation
+	    for sudden changes of system time is <c>enabled</c> or <c>disabled</c>.
+	    Such compensation is <c>enabled</c> when the
+	    <seealso marker="#system_info_time_offset">time offset</seealso> is
+	    <c>final</c>, and
+	    <seealso marker="#system_info_time_correction">time correction</seealso>
+	    is enabled.</p>
           </item>
           <tag><c>trace_control_word</c></tag>
           <item>
@@ -6609,7 +6965,44 @@ ok
         </note>
       </desc>
     </func>
+    <func>
+      <name name="system_time" arity="0"/>
+      <fsummary>Current Erlang system time</fsummary>
+      <desc>
+	<p>Returns current
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso>
+	in <c>native</c>
+	<seealso marker="#type_time_unit">time unit</seealso>.</p>
 
+	<p>Calling <c>erlang:system_time()</c> is equivalent to: 
+	<seealso marker="#monotonic_time/0"><c>erlang:monotonic_time()</c></seealso><c>
+	+
+        </c><seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso>.</p>
+
+	<note><p>This time is <em>not</em> a monotonically increasing time
+	in the general case. For more information, see the documentation of
+	<seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the
+	ERTS User's Guide.</p></note>
+      </desc>
+    </func>
+    <func>
+      <name name="system_time" arity="1"/>
+      <fsummary>Current Erlang system time</fsummary>
+      <desc>
+	<p>Returns current
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso>
+	converted into the <c><anno>Unit</anno></c> passed as argument.</p>
+
+	<p>Calling <c>erlang:system_time(<anno>Unit</anno>)</c> is equivalent to: 
+	<seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#system_time/0"><c>erlang:system_time()</c></seealso><c>,
+	native, <anno>Unit</anno>)</c>.</p>
+
+	<note><p>This time is <em>not</em> a monotonically increasing time
+	in the general case. For more information, see the documentation of
+	<seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the
+	ERTS User's Guide.</p></note>
+      </desc>
+    </func>
     <func>
       <name name="term_to_binary" arity="1"/>
       <fsummary>Encode a term to an Erlang external term format binary</fsummary>
@@ -6686,6 +7079,88 @@ ok
       </desc>
     </func>
     <func>
+      <name name="time_offset" arity="0"/>
+      <fsummary>Current time offset</fsummary>
+      <desc>
+	<p>Returns the current time offset between
+	<seealso marker="time_correction#Erlang_Monotonic_Time">Erlang monotonic time</seealso>
+	and
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso> in
+	<c>native</c> <seealso marker="#type_time_unit">time unit</seealso>.
+	Current time offset added to an Erlang monotonic time gives
+	corresponding Erlang system time.</p>
+
+	<p>The time offset may or may not change during operation depending
+	on the <seealso marker="time_correction#Time_Warp_Modes">time
+	warp mode</seealso> used.</p>
+
+	<note>
+	  <p>A change in time offset may be observed at slightly
+	  different points in time by different processes.</p>
+
+	  <p>If the runtime system is in
+	  <seealso marker="time_correction#Multi_Time_Warp_Mode">multi
+	  time warp mode</seealso>, the time offset will be changed when
+	  the runtime system detects that the
+	  <seealso marker="time_correction#OS_System_Time">OS system
+	  time</seealso> has changed. The runtime system will, however,
+	  not detect this immediately when it happens. A task checking
+	  the time offset is scheduled to execute at least once a minute,
+	  so under normal operation this should be detected within a
+	  minute, but during heavy load it might take longer time.</p>
+	</note>
+      </desc>
+    </func>
+    <func>
+      <name name="time_offset" arity="1"/>
+      <fsummary>Current time offset</fsummary>
+      <desc>
+	<p>Returns the current time offset between
+	<seealso marker="time_correction#Erlang_Monotonic_Time">Erlang monotonic time</seealso>
+	and
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso>
+	converted into the <c><anno>Unit</anno></c> passed as argument.</p>
+
+	<p>Same as calling	
+	<seealso marker="#convert_time_unit/3"><c>erlang:convert_time_unit</c></seealso><c>(</c><seealso marker="#time_offset/0"><c>erlang:time_offset()</c></seealso><c>, native, <anno>Unit</anno>)</c>
+	however optimized for commonly used <c><anno>Unit</anno></c>s.</p>
+      </desc>
+    </func>
+    <func>
+      <name name="timestamp" arity="0"/>
+      <type name="timestamp"/>
+      <fsummary>Current Erlang System time</fsummary>
+      <desc>
+	<p>Returns current
+	<seealso marker="time_correction#Erlang_System_Time">Erlang system time</seealso>
+	on the format <c>{MegaSecs, Secs, MicroSecs}</c>. This format is 
+	the same that <seealso marker="kernel:os#timestamp/0"><c>os:timestamp/0</c></seealso>
+	and the now deprecated <seealso marker="#now/0"><c>erlang:now/0</c></seealso>
+	uses. The reason for the existence of <c>erlang:timestamp()</c> is
+	purely to simplify usage for existing code that assumes this timestamp
+	format. Current Erlang system time can more efficiently be retrieved in
+	the time unit of your choice using
+	<seealso marker="#system_time/1"><c>erlang:system_time/1</c></seealso>.</p>
+
+	<p>The <c>erlang:timestamp()</c> BIF is equivalent to:</p><code type="none">
+timestamp() ->
+    ErlangSystemTime = erlang:system_time(micro_seconds),
+    MegaSecs = ErlangSystemTime div 1000000000000,
+    Secs = ErlangSystemTime div 1000000 - MegaSecs*1000000,
+    MicroSecs = ErlangSystemTime rem 1000000,
+    {MegaSecs, Secs, MicroSecs}.</code>
+        <p>It however use a native implementation which does
+	not build garbage on the heap and with slightly better
+	performance.</p>
+
+	<note><p>This time is <em>not</em> a monotonically increasing time
+	in the general case. For more information, see the documentation of
+	<seealso marker="time_correction#Time_Warp_Modes">time warp modes</seealso> in the
+	ERTS User's Guide.</p></note>
+      </desc>
+
+    </func>
+    <func>
       <name name="tl" arity="1"/>
       <fsummary>Tail of a list</fsummary>
       <desc>
@@ -7452,6 +7927,100 @@ ok
       </desc>
     </func>
     <func>
+      <name name="unique_integer" arity="0"/>
+      <fsummary>Get a unique integer value</fsummary>
+      <desc>
+	<p>Generates and returns an
+	<seealso marker="doc/efficiency_guide:advanced#unique_integers">integer
+	unique on current runtime system instance</seealso>. The same as calling
+	<seealso marker="#unique_integer/1"><c>erlang:unique_integer([])</c></seealso>.</p>
+      </desc>
+    </func>
+    <func>
+      <name name="unique_integer" arity="1"/>
+      <fsummary>Get a unique integer value</fsummary>
+      <desc>
+	<p>Generates and returns an
+	<seealso marker="doc/efficiency_guide:advanced#unique_integers">integer
+	unique on current runtime system
+	instance</seealso>. The integer is unique in the
+	sense that this BIF, using the same set of
+	modifiers, will not return the same integer more
+	than once on the current runtime system instance.
+	Each integer value can of course be constructed
+	by other means.</p>
+
+	<p>By default, i.e. when <c>[]</c> is passed as
+	<c><anno>ModifierList</anno></c>, both negative and
+	positive integers will be returned. This is order
+	to be able to utilize the range of integers that do
+	not need to be heap allocated as much as possible.
+	By default the returned integers are also only
+	guaranteed to be unique, i.e., any integer returned
+	may be either smaller, or larger than previously
+	returned integers.</p>
+
+	<p>Currently valid <c><anno>Modifier</anno></c>s:</p>
+	<taglist>
+
+	  <tag>positive</tag>
+	  <item><p>Return only positive integers.</p>
+	  <p>Note that by passing the <c>positive</c> modifier
+	  you will get heap allocated integers (big-nums)
+	  quicker.</p>
+	  </item>
+
+	  <tag>monotonic</tag>
+	  <item><p>Return
+	  <seealso marker="time_correction#Strictly_Monotonically_Increasing">strictly
+	  monotonically increasing</seealso> integers
+	  corresponding to creation time. That is, the integer
+	  returned will always be larger than previously
+	  returned integers on the current runtime system
+	  instance.</p>
+	  <p>These values can be used when ordering events
+	  on the runtime system instance. That is, if both
+	  <c>X = erlang:unique_integer([monotonic])</c> and
+	  <c>Y = erlang:unique_integer([monotonic])</c> are
+	  executed by different processes (or the same
+	  process) on the same runtime system instance and
+	  <c>X &lt; Y</c> we know that <c>X</c> was created
+	  before <c>Y</c>.</p>
+	  <warning><p>Strictly monotonically increasing values
+	  are inherently quite expensive to generate and scales
+	  poorly. This since the values needs to be
+	  synchronized. That is, do not pass the <c>monotonic</c>
+	  modifier unless you really need strictly monotonically
+	  increasing values.</p></warning>
+	  </item>
+
+	</taglist>
+
+	<p>All currently valid <c><anno>Modifier</anno></c>s
+	can be combined. Repeated (valid)
+	<c><anno>Modifier</anno></c>s in the <c>ModifierList</c>
+	are ignored.</p>
+
+	<note><p>Note that the set of integers returned by
+	<c>unique_integer/1</c> using diffrent sets of
+	<c><anno>Modifier</anno></c>s <em>will overlap</em>.
+	For example, by calling	<c>unique_integer([monotonic])</c>,
+	and <c>unique_integer([positive, monotonic])</c>
+	repeatedly, you will eventually see some integers being
+	returned by both calls.</p></note>
+
+        <p>Failures:</p>
+	<taglist>
+	  <tag><c>badarg</c></tag>
+	  <item>if <c><anno>ModifierList</anno></c> is not a
+	  proper list.</item>
+	  <tag><c>badarg</c></tag>
+	  <item>if <c><anno>Modifier</anno></c> is not a
+	  valid modifier.</item>
+	</taglist>
+      </desc>
+    </func>
+    <func>
       <name name="unlink" arity="1"/>
       <fsummary>Remove a link, if there is one, to another process or port</fsummary>
       <desc>