Merge branch 'master' into sverker/enif_select

5 files changed, 328 insertions, 78 deletions

diff --git a/erts/doc/src/absform.xml b/erts/doc/src/absform.xml
index ab00d47425..fe8e3b30e7 100644
--- a/erts/doc/src/absform.xml
+++ b/erts/doc/src/absform.xml
@@ -886,7 +886,7 @@
         Rep(Fc) = <c>[Rep(C_1), ..., Rep(C_k)]</c>.</p>
 
       <list type="bulleted">
-        <item>If C is a constraint <c>is_subtype(V, T)</c> or <c>V :: T</c>,
+        <item>If C is a constraint <c>V :: T</c>,
           where <c>V</c> is a type variable
           and <c>T</c> is a type, then Rep(C) =
           <c>{type,LINE,constraint,[{atom,LINE,is_subtype},[Rep(V),Rep(T)]]}</c>.
diff --git a/erts/doc/src/erl.xml b/erts/doc/src/erl.xml
index f2a55f6298..4e32118405 100644
--- a/erts/doc/src/erl.xml
+++ b/erts/doc/src/erl.xml
@@ -946,9 +946,7 @@
 	  schedulers was allowed to be unlimited, dirty CPU bound jobs would
 	  potentially starve normal jobs.</p>
         <p>This option is ignored if the emulator does not have threading
-          support enabled. <em>This option is experimental</em> and
-          is supported only if the emulator was configured and built with
-          support for dirty schedulers enabled (it is disabled by default).</p>
+          support enabled.</p>
       </item>
       <tag><marker id="+SDPcpu"/><c><![CDATA[+SDPcpu
         DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercentage]]></c></tag>
@@ -974,9 +972,7 @@
           either order) results in 2 dirty CPU scheduler threads (50% of 4) and
           1 dirty CPU scheduler thread online (25% of 4).</p>
         <p>This option is ignored if the emulator does not have threading
-          support enabled. <em>This option is experimental</em> and
-          is supported only if the emulator was configured and built with
-          support for dirty schedulers enabled (it is disabled by default).</p>
+          support enabled.</p>
       </item>
       <tag><marker id="+SDio"/><c><![CDATA[+SDio DirtyIOSchedulers]]></c></tag>
       <item>
@@ -992,9 +988,7 @@
 	  bound jobs on dirty I/O schedulers, these jobs might starve ordinary
 	  jobs executing on ordinary schedulers.</p>
         <p>This option is ignored if the emulator does not have threading
-          support enabled. <em>This option is experimental</em> and
-          is supported only if the emulator was configured and built with
-          support for dirty schedulers enabled (it is disabled by default).</p>
+          support enabled.</p>
       </item>
       <tag><c><![CDATA[+sFlag Value]]></c></tag>
       <item>
@@ -1595,6 +1589,25 @@
   </section>
 
   <section>
+      <marker id="signals"></marker>
+      <title>Signals</title>
+      <p>On Unix systems, the Erlang runtime will interpret two types of signals.</p>
+      <taglist>
+          <tag><c>SIGUSR1</c></tag>
+          <item>
+              <p>A <c>SIGUSR1</c> signal forces a crash dump.</p>
+          </item>
+          <tag><c>SIGTERM</c></tag>
+          <item>
+              <p>A <c>SIGTERM</c> will produce a <c>stop</c> message to the <c>init</c> process.
+                  This is equivalent to a <c>init:stop/0</c> call.</p>
+              <p>Introduced in ERTS 8.3 (Erlang/OTP 19.3)</p>
+          </item>
+      </taglist>
+      <p>The signal <c>SIGUSR2</c> is reserved for internal usage. No other signals are handled.</p>
+  </section>
+
+  <section>
     <marker id="configuration"></marker>
     <title>Configuration</title>
     <p>The standard Erlang/OTP system can be reconfigured to change the default
diff --git a/erts/doc/src/erl_nif.xml b/erts/doc/src/erl_nif.xml
index 13b72863f3..8cdfc80879 100644
--- a/erts/doc/src/erl_nif.xml
+++ b/erts/doc/src/erl_nif.xml
@@ -123,7 +123,7 @@ ok
 "Hello world!"</code>
 
     <p>A better solution for a real module is to take advantage of the new
-      directive <c>on load</c> (see section
+      directive <c>on_load</c> (see section
       <seealso marker="doc/reference_manual:code_loading#on_load">Running a
       Function When a Module is Loaded</seealso> in the Erlang Reference
       Manual) to load the NIF library automatically when the module is
@@ -135,27 +135,14 @@ ok
         away by the compiler, causing loading of the NIF library to fail.</p>
     </note>
 
-    <p>A loaded NIF library is tied to the Erlang module code version
-      that loaded it. If the module is upgraded with a new version, the
-      new Erlang code need to load its own NIF library (or maybe choose not
-      to). The new code version can, however, choose to load the
-      same NIF library as the old code if it wants to. Sharing the
-      dynamic library means that static data defined by the library
-      is shared as well. To avoid unintentionally shared static
-      data, each Erlang module code can keep its own private data. This
-      private data can be set when the NIF library is loaded and
-      then retrieved by calling <seealso marker="#enif_priv_data">
-      <c>enif_priv_data</c></seealso>.</p>
-
-    <p>A NIF library cannot be loaded explicitly. A library is
-      automatically unloaded when the module code that it belongs to is purged
-      by the code server.</p>
+    <p>Once loaded, a NIF library is persistent. It will not be unloaded
+      until the module code version that it belongs to is purged.</p>
   </description>
 
   <section>
   <title>Functionality</title>
-    <p>All functions that a NIF library needs to do with Erlang are
-      performed through the NIF API functions. Functions exist
+    <p>All interaction between NIF code and the Erlang runtime system is
+      performed by calling NIF API functions. Functions exist
       for the following functionality:</p>
 
     <taglist>
@@ -286,6 +273,19 @@ return term;</code>
           library is postponed as long as there exist resource objects with a
           destructor function in the library.</p>
       </item>
+      <tag>Module upgrade and static data</tag>
+      <item>
+	<p>A loaded NIF library is tied to the Erlang module instance
+	that loaded it. If the module is upgraded, the new module instance
+	needs to load its own NIF library (or maybe choose not to). The new
+	module instance can, however, choose to load the exact same NIF library
+	as the old code if it wants to. Sharing the dynamic library means that
+	static data defined by the library is shared as well. To avoid
+	unintentionally shared static data between module instances, each Erlang
+	module version can keep its own private data. This private data can be
+	set when the NIF library is loaded and later retrieved by calling
+	<seealso marker="#enif_priv_data"><c>enif_priv_data</c></seealso>.</p>
+      </item>
       <tag>Threads and concurrency</tag>
       <item>
         <p>A NIF is thread-safe without any explicit synchronization as
@@ -402,14 +402,14 @@ return term;</code>
           <tag><marker id="dirty_nifs"/>Dirty NIF</tag>
           <item>
             <note>
-              <p><em>The dirty NIF functionality described here
-                is experimental</em>. Dirty NIF support is available only when
-                the emulator is configured with dirty schedulers enabled. This
-                feature is disabled by default. The Erlang runtime
-                without SMP support does not support dirty schedulers even when
-                the dirty scheduler support is enabled. To check at runtime for
-                the presence of dirty scheduler threads, code can use the
-                <seealso marker="#enif_system_info">
+              <p>Dirty NIF support is available only when the emulator is
+	        configured with dirty scheduler support. As of ERTS version
+		9.0, dirty scheduler support is enabled by default on the
+		runtime system with SMP support. The Erlang runtime without
+		SMP support does <em>not</em> support dirty schedulers even
+		when the dirty scheduler support is explicitly enabled. To
+		check at runtime for the presence of dirty scheduler threads,
+		code can use the <seealso marker="#enif_system_info">
                 <c>enif_system_info()</c></seealso> API function.</p>
             </note>
             <p>A NIF that cannot be split and cannot execute in a millisecond
@@ -525,7 +525,7 @@ return term;</code>
         <p><c>load</c> is called when the NIF library is loaded
           and no previously loaded library exists for this module.</p>
         <p><c>*priv_data</c> can be set to point to some private data
-          that the library needs to keep a state between NIF
+          if the library needs to keep a state between NIF
           calls. <c>enif_priv_data</c> returns this pointer.
           <c>*priv_data</c> is initialized to <c>NULL</c> when <c>load</c> is
           called.</p> 
@@ -642,9 +642,6 @@ typedef struct {
             <p><c>flags</c> can be used to indicate that the NIF is a
               <seealso marker="#dirty_nifs">dirty NIF</seealso> that is to be
               executed on a dirty scheduler thread.</p>
-            <p><em>The dirty NIF functionality described here is
-              experimental.</em> You have to enable support for dirty
-              schedulers when building OTP to try out the functionality.</p>
             <p>If the dirty NIF is expected to be CPU-bound, its <c>flags</c>
               field is to be set to <c>ERL_NIF_DIRTY_JOB_CPU_BOUND</c> or
               <c>ERL_NIF_DIRTY_JOB_IO_BOUND</c>.</p>
@@ -2488,9 +2485,6 @@ enif_map_iterator_destroy(env, &amp;iter);</code>
           application to break up long-running work into multiple regular NIF
           calls or to schedule a <seealso marker="#dirty_nifs">
           dirty NIF</seealso> to execute on a dirty scheduler thread.</p>
-        <p><em>The dirty NIF functionality described here is
-          experimental.</em> You have to enable support for dirty
-          schedulers when building OTP to try out the functionality.</p>
         <taglist>
           <tag><c>fun_name</c></tag>
           <item>
@@ -2501,7 +2495,7 @@ enif_map_iterator_destroy(env, &amp;iter);</code>
           <tag><c>flags</c></tag>
           <item>
             <p>Must be set to <c>0</c> for a regular NIF. If the emulator was
-              built with the experimental dirty scheduler support enabled,
+              built with dirty scheduler support enabled,
               <c>flags</c> can be set to either
               <c>ERL_NIF_DIRTY_JOB_CPU_BOUND</c> if the job is expected to be
               CPU-bound, or <c>ERL_NIF_DIRTY_JOB_IO_BOUND</c> for
diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml
index 3dad09365e..7815bfa510 100644
--- a/erts/doc/src/erlang.xml
+++ b/erts/doc/src/erlang.xml
@@ -4933,7 +4933,9 @@ RealSystem = system + MissedSystem</code>
             <p>Returns the current call stack back-trace (<em>stacktrace</em>)
               of the process. The stack has the same format as returned by
               <seealso marker="#get_stacktrace/0">
-              <c>erlang:get_stacktrace/0</c></seealso>.</p>
+              <c>erlang:get_stacktrace/0</c></seealso>. The depth of the
+              stacktrace is truncated according to the <c>backtrace_depth</c>
+              system flag setting.</p>
           </item>
           <tag><c>{dictionary, <anno>Dictionary</anno>}</c></tag>
           <item>
@@ -6413,12 +6415,17 @@ lists:map(
           <c><anno>TotalTime</anno></c> is the total time duration since
           <seealso marker="#system_flag_scheduler_wall_time">
           <c>scheduler_wall_time</c></seealso>
-          activation. The time unit is undefined and can be subject
-          to change between releases, OSs, and system restarts.
-          <c>scheduler_wall_time</c> is only to be used to
-          calculate relative values for scheduler-utilization.
-          <c><anno>ActiveTime</anno></c> can never exceed
-          <c><anno>TotalTime</anno></c>.</p>
+          activation for the specific scheduler. Note that
+	  activation time can differ significantly between
+	  schedulers. Currently dirty schedulers are activated
+	  at system start while normal schedulers are activated
+	  some time after the <c>scheduler_wall_time</c>
+	  functionality is enabled. The time unit is undefined
+	  and can be subject to change between releases, OSs,
+	  and system restarts. <c>scheduler_wall_time</c> is only
+	  to be used to calculate relative values for scheduler
+	  utilization. <c><anno>ActiveTime</anno></c> can never
+	  exceed <c><anno>TotalTime</anno></c>.</p>
         <p>The definition of a busy scheduler is when it is not idle
           and is not scheduling (selecting) a process or port,
           that is:</p>
@@ -6436,15 +6443,37 @@ lists:map(
           <c>scheduler_wall_time</c></seealso> is turned off.</p>
         <p>The list of scheduler information is unsorted and can
           appear in different order between calls.</p>
+	<p>As of ERTS version 9.0, also dirty CPU schedulers will
+	be included 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
+	<seealso marker="#statistics_scheduler_wall_time_all"><c>statistics(scheduler_wall_time_all)</c></seealso>
+	instead.</p>
+	
+	<p>Normal schedulers will have scheduler identifiers in
+	the range <c>1 =&lt; <anno>SchedulerId</anno> =&lt;
+	</c><seealso marker="#system_info_schedulers"><c>erlang:system_info(schedulers)</c></seealso>.
+	Dirty CPU schedulers will have scheduler identifiers in
+	the range <c>erlang:system_info(schedulers) &lt;
+	<anno>SchedulerId</anno> =&lt; erlang:system_info(schedulers)
+	+
+	</c><seealso marker="#system_info_dirty_cpu_schedulers"><c>erlang:system_info(dirty_cpu_schedulers)</c></seealso>.
+	</p>
+	<note><p>The different types of schedulers handle
+	specific types of jobs. Every job is assigned to a specific
+	scheduler type. Jobs can migrate 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.</p></note>
         <p>Using <c>scheduler_wall_time</c> to calculate
-          scheduler-utilization:</p>
+          scheduler utilization:</p>
         <pre>
 > <input>erlang:system_flag(scheduler_wall_time, true).</input>
 false
 > <input>Ts0 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.</input>
 ok</pre>
         <p>Some time later the user takes another snapshot and calculates
-          scheduler-utilization per scheduler, for example:</p>
+          scheduler utilization per scheduler, for example:</p>
         <pre>
 > <input>Ts1 = lists:sort(erlang:statistics(scheduler_wall_time)), ok.</input>
 ok
@@ -6459,11 +6488,32 @@ ok
  {7,0.973237033077876},
  {8,0.9741297293248656}]</pre>
         <p>Using the same snapshots to calculate a total
-          scheduler-utilization:</p>
+          scheduler utilization:</p>
         <pre>
 > <input>{A, T} = lists:foldl(fun({{_, A0, T0}, {_, A1, T1}}, {Ai,Ti}) ->
-	{Ai + (A1 - A0), Ti + (T1 - T0)} end, {0, 0}, lists:zip(Ts0,Ts1)), A/T.</input>
+	{Ai + (A1 - A0), Ti + (T1 - T0)} end, {0, 0}, lists:zip(Ts0,Ts1)),
+	TotalSchedulerUtilization = A/T.</input>
+0.9769136803764825</pre>
+        <p>Total scheduler utilization will equal <c>1.0</c> when
+	all schedulers have been active all the time between the
+	two measurements.</p>
+	<p>Another (probably more) useful value is to calculate
+	total scheduler utilization weighted against maximum amount
+	of available CPU time:</p>
+        <pre>
+> <input>WeightedSchedulerUtilization = (TotalSchedulerUtilization
+                                  * (erlang:system_info(schedulers)
+                                     + erlang:system_info(dirty_cpu_schedulers)))
+                                 / erlang:system_info(logical_processors_available).</input>
 0.9769136803764825</pre>
+        <p>This weighted scheduler utilization will reach <c>1.0</c>
+	when schedulers are active the same amount of time as
+	maximum available CPU time. If more schedulers exist
+	than available logical processors, this value may
+	be greater than <c>1.0</c>.</p>
+	<p>As of ERTS version 9.0, the Erlang runtime system
+	with SMP support will as default have more schedulers
+	than logical processors. This due to the dirty schedulers.</p>
         <note>
           <p><c>scheduler_wall_time</c> is by default disabled. To
             enable it, use
@@ -6474,6 +6524,31 @@ ok
 
     <func>
       <name name="statistics" arity="1" clause_i="12"/>
+      <fsummary>Information about each schedulers work time.</fsummary>
+      <desc>
+        <marker id="statistics_scheduler_wall_time_all"></marker>
+	<p>The same as
+	<seealso marker="#statistics_scheduler_wall_time"><c>statistics(scheduler_wall_time)</c></seealso>,
+	except that it also include information about all dirty I/O
+	schedulers.</p>
+	<p>Dirty IO schedulers will have scheduler identifiers in
+	the range
+	<seealso marker="#system_info_schedulers"><c>erlang:system_info(schedulers)</c></seealso><c>
+	+
+	</c><seealso marker="#system_info_dirty_cpu_schedulers"><c>erlang:system_info(dirty_cpu_schedulers)</c></seealso><c> &lt;
+	<anno>SchedulerId</anno> =&lt; erlang:system_info(schedulers)
+	+ erlang:system_info(dirty_cpu_schedulers)
+	+
+	</c><seealso marker="#system_info_dirty_io_schedulers"><c>erlang:system_info(dirty_io_schedulers)</c></seealso>.</p>
+	<note><p>Note that work executing on dirty I/O schedulers
+	are expected to mainly wait for I/O. That is, when you
+	get high scheduler utilization on dirty I/O schedulers,
+	CPU utilization is <em>not</em> expected to be high due to
+	this work.</p></note>
+      </desc>
+    </func>
+    <func>
+      <name name="statistics" arity="1" clause_i="13"/>
       <fsummary>Information about active processes and ports.</fsummary>
       <desc><marker id="statistics_total_active_tasks"></marker>
         <p>Returns the total amount of active processes and ports in
@@ -6493,7 +6568,7 @@ ok
     </func>
 
     <func>
-      <name name="statistics" arity="1" clause_i="13"/>
+      <name name="statistics" arity="1" clause_i="14"/>
       <fsummary>Information about the run-queue lengths.</fsummary>
       <desc><marker id="statistics_total_run_queue_lengths"></marker>
         <p>Returns the total length of the run queues. That is, the number
@@ -6513,7 +6588,7 @@ ok
     </func>
 
     <func>
-      <name name="statistics" arity="1" clause_i="14"/>
+      <name name="statistics" arity="1" clause_i="15"/>
       <fsummary>Information about wall clock.</fsummary>
       <desc>
         <p>Returns information about wall clock. <c>wall_clock</c> can
@@ -6645,7 +6720,9 @@ ok
       <fsummary>Set system flag <c>backtrace_depth</c>.</fsummary>
       <desc>
         <p>Sets the maximum depth of call stack back-traces in the
-          exit reason element of <c>'EXIT'</c> tuples.</p>
+          exit reason element of <c>'EXIT'</c> tuples. The flag
+          also limits the stacktrace depth returned by <c>process_info</c>
+          item <c>current_stacktrace.</c></p>
         <p>Returns the old value of the flag.</p>
       </desc>
     </func>
@@ -6717,11 +6794,6 @@ ok
           down to 3. Similarly, the number of dirty CPU schedulers
           online increases proportionally to increases in the number of
           schedulers online.</p>
-        <note>
-          <p>The dirty schedulers functionality is experimental.
-            Enable support for dirty schedulers when building OTP to
-            try out the functionality.</p>
-        </note>
         <p>For more information, see
           <seealso marker="#system_info_dirty_cpu_schedulers">
           <c>erlang:system_info(dirty_cpu_schedulers)</c></seealso> and
@@ -7224,8 +7296,8 @@ ok
     </func>
 
     <func>
-      <name name="system_info" arity="1" clause_i="11"/>
       <name name="system_info" arity="1" clause_i="12"/>
+      <name name="system_info" arity="1" clause_i="13"/>
       <fsummary>Information about the CPU topology of the system.</fsummary>
       <type name="cpu_topology"/>
       <type name="level_entry"/>
@@ -7325,12 +7397,12 @@ ok
     </func>
 
     <func>
-      <name name="system_info" arity="1" clause_i="28"/>
       <name name="system_info" arity="1" clause_i="29"/>
-      <name name="system_info" arity="1" clause_i="37"/>
+      <name name="system_info" arity="1" clause_i="30"/>
       <name name="system_info" arity="1" clause_i="38"/>
       <name name="system_info" arity="1" clause_i="39"/>
       <name name="system_info" arity="1" clause_i="40"/>
+      <name name="system_info" arity="1" clause_i="41"/>
       <fsummary>Information about the default process heap settings.</fsummary>
       <type name="message_queue_data"/>
       <type name="max_heap_size"/>
@@ -7408,7 +7480,7 @@ ok
       <name name="system_info" arity="1" clause_i="8"/>
       <name name="system_info" arity="1" clause_i="9"/>
       <name name="system_info" arity="1" clause_i="10"/>
-      <name name="system_info" arity="1" clause_i="13"/>
+      <name name="system_info" arity="1" clause_i="11"/>
       <name name="system_info" arity="1" clause_i="14"/>
       <name name="system_info" arity="1" clause_i="15"/>
       <name name="system_info" arity="1" clause_i="16"/>
@@ -7423,14 +7495,14 @@ ok
       <name name="system_info" arity="1" clause_i="25"/>
       <name name="system_info" arity="1" clause_i="26"/>
       <name name="system_info" arity="1" clause_i="27"/>
-      <name name="system_info" arity="1" clause_i="30"/>
+      <name name="system_info" arity="1" clause_i="28"/>
       <name name="system_info" arity="1" clause_i="31"/>
       <name name="system_info" arity="1" clause_i="32"/>
       <name name="system_info" arity="1" clause_i="33"/>
       <name name="system_info" arity="1" clause_i="34"/>
       <name name="system_info" arity="1" clause_i="35"/>
       <name name="system_info" arity="1" clause_i="36"/>
-      <name name="system_info" arity="1" clause_i="41"/>
+      <name name="system_info" arity="1" clause_i="37"/>
       <name name="system_info" arity="1" clause_i="42"/>
       <name name="system_info" arity="1" clause_i="43"/>
       <name name="system_info" arity="1" clause_i="44"/>
@@ -7460,11 +7532,18 @@ ok
       <name name="system_info" arity="1" clause_i="68"/>
       <name name="system_info" arity="1" clause_i="69"/>
       <name name="system_info" arity="1" clause_i="70"/>
+      <name name="system_info" arity="1" clause_i="71"/>
       <fsummary>Information about the system.</fsummary>
       <desc>
         <p>Returns various information about the current system
           (emulator) as specified by <c><anno>Item</anno></c>:</p>
         <taglist>
+          <tag><c>atom_count</c></tag>
+          <item>
+            <marker id="system_info_atom_count"></marker>
+            <p>Returns the number of atoms currently existing at the
+              local node. The value is given as an integer.</p>
+          </item>
           <tag><c>atom_limit</c></tag>
           <item>
             <marker id="system_info_atom_limit"></marker>
@@ -7559,9 +7638,6 @@ ok
               <seealso marker="erts:erl#+SDcpu"><c>+SDcpu</c></seealso> or
               <seealso marker="erts:erl#+SDPcpu"><c>+SDPcpu</c></seealso> in
               <c>erl(1)</c>.</p>
-            <p>Notice that the dirty schedulers functionality is
-              experimental. Enable support for dirty schedulers when
-              building OTP to try out the functionality.</p>
             <p>See also
               <seealso marker="#system_flag_dirty_cpu_schedulers_online">
               <c>erlang:system_flag(dirty_cpu_schedulers_online,
@@ -7591,9 +7667,6 @@ ok
               startup by passing command-line flag
               <seealso marker="erts:erl#+SDcpu"><c>+SDcpu</c></seealso> in
               <c>erl(1)</c>.</p>
-	    <p>Notice that the dirty schedulers functionality is
-              experimental. Enable support for dirty schedulers when
-              building OTP to try out the functionality.</p>
             <p>For more information, see
               <seealso marker="#system_info_dirty_cpu_schedulers">
               <c>erlang:system_info(dirty_cpu_schedulers)</c></seealso>,
@@ -7615,9 +7688,6 @@ ok
             <p>This value can be set at startup by passing command-line
               argument <seealso marker="erts:erl#+SDio"><c>+SDio</c></seealso>
               in <c>erl(1)</c>.</p>
-            <p>Notice that the dirty schedulers functionality is
-              experimental. Enable support for dirty schedulers when
-              building OTP to try out the functionality.</p>
             <p>For more information, see
               <seealso marker="#system_info_dirty_cpu_schedulers">
               <c>erlang:system_info(dirty_cpu_schedulers)</c></seealso>,
diff --git a/erts/doc/src/notes.xml b/erts/doc/src/notes.xml
index dd260f2d1f..812538729d 100644
--- a/erts/doc/src/notes.xml
+++ b/erts/doc/src/notes.xml
@@ -32,6 +32,179 @@
   <p>This document describes the changes made to the ERTS application.</p>
 
 
+<section><title>Erts 8.2.1</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+	    Fix a quite rare bug causing VM crash during code loading
+	    and the use of export funs (fun M:F/A) of not yet loaded
+	    modules. Requires a very specfic timing of concurrent
+	    scheduler threads. Has been seen on ARM but can probably
+	    also occure on other architectures. Bug has existed since
+	    OTP R16.</p>
+          <p>
+	    Own Id: OTP-14144 Aux Id: seq13242 </p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
+<section><title>Erts 8.2</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+          <p>
+	    Fixed <c>configure</c> failures on MacOSX. Most important
+	    <c>clock_gettime()</c> was detected when building for
+	    MacOSX - El Capitan using XCode 8 despite it is not
+	    available until MacOSX - Sierra.</p>
+          <p>
+	    Own Id: OTP-13904 Aux Id: ERL-256 </p>
+        </item>
+        <item>
+          <p>
+	    <c>code:add_pathsa/1</c> and command line option
+	    <c>-pa</c> both revert the given list of directories when
+	    adding it at the beginning of the code path. This is now
+	    documented.</p>
+          <p>
+	    Own Id: OTP-13920 Aux Id: ERL-267 </p>
+        </item>
+        <item>
+          <p>
+	    Fix a compilation error of erts in OpenBSD related to the
+	    usage of the __errno variable.</p>
+          <p>
+	    Own Id: OTP-13927</p>
+        </item>
+        <item>
+          <p>
+	    Fixed so that when enabling tracing on a process that had
+	    an invalid tracer associated with it, the new tracer
+	    overwrites the old tracer. Before this fix, calling
+	    erlang:trace/3 would behave as if the tracer was still
+	    alive and not apply the new trace.</p>
+          <p>
+	    This fault was introduced in ERTS 8.0.</p>
+          <p>
+	    Own Id: OTP-13928</p>
+        </item>
+        <item>
+          <p>
+	    Fix parsing of <c>-profile_boot 'true' | 'false'</c></p>
+          <p>
+	    Own Id: OTP-13955 Aux Id: ERL-280 </p>
+        </item>
+        <item>
+          <p>
+	    A slight improvement of <c>erlang:get_stacktrace/0</c>
+	    for exceptions raised in hipe compiled code. Beam
+	    compiled functions in such stack trace was earlier
+	    replaced by some unrelated function. They are now instead
+	    omitted. This is an attempt to reduce the confusion in
+	    the absence of a complete and correct stack trace for
+	    mixed beam and hipe functions.</p>
+          <p>
+	    Own Id: OTP-13992</p>
+        </item>
+        <item>
+	    <p> Correct type declaration of match specification head.
+	    </p>
+          <p>
+	    Own Id: OTP-13996</p>
+        </item>
+        <item>
+          <p>
+	    HiPE code loading failed for x86_64 if gcc was configured
+	    with <c>--enable-default-pie</c>. Fixed by disabling PIE,
+	    if needed for HiPE, when building the VM.</p>
+          <p>
+	    Own Id: OTP-14031 Aux Id: ERL-294, PR-1239 </p>
+        </item>
+        <item>
+          <p>
+	    Faulty arguments could be presented on exception from a
+	    NIF that had rescheduled itself using
+	    <c>enif_schedule_nif()</c>.</p>
+          <p>
+	    Own Id: OTP-14048</p>
+        </item>
+        <item>
+          <p>
+	    The runtime system could crash if a garbage collection on
+	    a process was performed immediately after a NIF had been
+	    rescheduled using <c>enif_schedule_nif()</c>.</p>
+          <p>
+	    Own Id: OTP-14049</p>
+        </item>
+        <item>
+          <p>
+	    A reference to purged code could be left undetected by
+	    the purge operation if a process just had rescheduled a
+	    NIF call using <c>enif_schedule_nif()</c> when the
+	    process was checked. This could cause a runtime system
+	    crash.</p>
+          <p>
+	    Own Id: OTP-14050</p>
+        </item>
+        <item>
+	    <p>Fixed a number of dirty scheduler related bugs:</p>
+	    <list> <item><p>Process priority was not handled correct
+	    when scheduling on a dirty scheduler.</p></item>
+	    <item><p>The runtime system could crash when an exit
+	    signal with a compound exit reason was sent to a process
+	    executing on a dirty scheduler.</p></item> <item><p>The
+	    runtime system crashed when call tracing a process
+	    executing on a dirty scheduler.</p></item> <item><p>A
+	    code purge operation could end up hanging forever when a
+	    process executed on a dirty scheduler</p></item> </list>
+          <p>
+	    Own Id: OTP-14051</p>
+        </item>
+      </list>
+    </section>
+
+
+    <section><title>Improvements and New Features</title>
+      <list>
+        <item>
+          <p>
+	    Fix minor soft purge race bug that could incorrectly
+	    trigger code_server to load new code for the module if
+	    the soft purge failed and no current version of the
+	    module existed.</p>
+          <p>
+	    Own Id: OTP-13925</p>
+        </item>
+        <item>
+          <p>
+	    To ease troubleshooting, <c>erlang:load_nif/2</c> now
+	    includes the return value from a failed call to
+	    load/reload/upgrade in the text part of the error tuple.
+	    The <c>crypto</c> NIF makes use of this feature by
+	    returning the source line where/if the initialization
+	    fails.</p>
+          <p>
+	    Own Id: OTP-13951</p>
+        </item>
+        <item>
+          <p>
+	    New environment variable <c>ERL_CRASH_DUMP_BYTES</c> can
+	    be used to limit the size of crash dumps. If the limit is
+	    reached, crash dump generation is aborted and the
+	    generated file will be truncated.</p>
+          <p>
+	    Own Id: OTP-14046</p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
 <section><title>Erts 8.1.1</title>
 
     <section><title>Fixed Bugs and Malfunctions</title>