From 66ca62d95cfaa6f37adefce978015181a5d82a43 Mon Sep 17 00:00:00 2001
From: Rickard Green <rickard@erlang.org>
Date: Wed, 30 May 2018 18:00:41 +0200
Subject: Update information about HiPE

---
 lib/hipe/doc/src/hipe_app.xml | 62 ++++++++++++++++++++++++++++++++++++-------
 1 file changed, 52 insertions(+), 10 deletions(-)

(limited to 'lib/hipe/doc/src/hipe_app.xml')

diff --git a/lib/hipe/doc/src/hipe_app.xml b/lib/hipe/doc/src/hipe_app.xml
index fc42ecd97d..4d40db086c 100644
--- a/lib/hipe/doc/src/hipe_app.xml
+++ b/lib/hipe/doc/src/hipe_app.xml
@@ -35,6 +35,14 @@
   <app>HiPE</app>
   <appsummary>The HiPE Application</appsummary>
   <description>
+    <note>
+      <p>
+	HiPE and execution of HiPE compiled code only have limited support by
+	the OTP team at Ericsson. The OTP team only does limited maintenance
+	of HiPE and does not actively develop HiPE. HiPE is mainly supported
+	by the HiPE team at Uppsala University.
+      </p>
+    </note>
     <p>
       The normal way to native-compile an Erlang module using HiPE is to include the atom native 
       in the Erlang compiler options, as in:</p>
@@ -108,7 +116,7 @@
 	  queue when the reference was created will be bypassed, as they
 	  cannot possibly contain the reference. HiPE currently has an
 	  optimization similar this, but it is not guaranteed to
-	  bypass all messages. In the worst case scenario it, cannot
+	  bypass all messages. In the worst case scenario, it cannot
 	  bypass any messages at all.
 	</p>
 	<p>
@@ -117,21 +125,55 @@
 	</p>
       </item>
 
+      <tag>Garbage collection after BIFs</tag>
+      <item>
+	<p>
+	  The condition for determining whether a garbage collection
+	  is needed or not has changed in later releases. HiPE has not
+	  been updated regarding this which may cause premature garbage
+	  collections after BIF calls.
+	</p>
+      </item>
+
     </taglist>
   </section>
   <section>
     <title>Stability Issues</title>
     <taglist>
-      <tag>Not yielding in <c>receive</c> statements</tag>
+      <tag>Not checking reduction count on function returns</tag>
       <item>
-	<p>HiPE will not yield in <c>receive</c> statements where
-	appropriate. If a process have lots of signals in its signal
-	queue and execute a HiPE compiled <c>receive</c> statement,
-	the scheduler thread performing the execution may be stuck
-	in the <c>receive</c> statement for a very long time. This
-	can in turn cause various severe issues such as for example
-	prevent the runtime system from being able to release
-	memory.
+	<p>
+	  BEAM checks the reduction count and schedules out the executing
+	  process if needed both when calling a function and when returning
+	  from a function call that was not called using a tail call.
+	  HiPE only checks the reduction count when calling a function.
+	</p>
+	<p>
+	  The runtime system might need to schedule out a process
+	  in order to reclaim memory. If the process isn't scheduled
+	  out soon after the process has entered this state, memory
+	  consumption will quickly grow. Maintaining this state is also
+	  quite expensive performance wise.
+	</p>
+	<p>
+	  Processes executing code that performs large recursions and
+	  produce data after returning from recursive calls may have to
+	  be scheduled out when returning from a function call. Since
+	  HiPE does not check reductions on returns, processes executing
+	  such HiPE compiled code may cause huge peeks in memory
+	  consumption as well as severe performance degradation.
+	</p>
+      </item>
+
+      <tag>Not bumping appropriate amount of reductions in <c>receive</c> statements</tag>
+      <item>
+	<p>
+	  The process signaling improvements made in ERTS version
+	  10.0 moved potentially significant amounts of work into the
+	  receive statement from other places. In order to account for
+	  this work, the reduction count should be bumped on the
+	  executing process. Reductions are not bumped when entering
+	  the <c>receive</c> statement from HiPE compiled code.
 	</p>
       </item>
     </taglist>
-- 
cgit v1.2.3