From 66ca62d95cfaa6f37adefce978015181a5d82a43 Mon Sep 17 00:00:00 2001 From: Rickard Green 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') 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 @@ HiPE The HiPE Application + +

+ 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. +

+

The normal way to native-compile an Erlang module using HiPE is to include the atom native in the Erlang compiler options, as in:

@@ -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.

@@ -117,21 +125,55 @@

+ Garbage collection after BIFs + +

+ 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. +

+
+
Stability Issues - Not yielding in receive statements + Not checking reduction count on function returns -

HiPE will not yield in receive statements where - appropriate. If a process have lots of signals in its signal - queue and execute a HiPE compiled receive statement, - the scheduler thread performing the execution may be stuck - in the receive 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. +

+ 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. +

+

+ 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. +

+

+ 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. +

+
+ + Not bumping appropriate amount of reductions in receive statements + +

+ 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 receive statement from HiPE compiled code.

-- cgit v1.2.3