[Erlang 0016] hipe SASL Monitor

Erlang uses some common parameters and commands of hipe SASL Monitor, which are recorded in this memo.

 

 

Compile and enable hipe (High Performance Erlang)

 

What is hipe?

The Overlord has a description in the phrase "Erlang's hipe is equivalent to JIT. According to the language evaluation, hipe supports 2-3 times faster in pure Erlang operations, this performance improvement is considerable for computing-intensive applications. "

JIT information on Wikipedia:

Instant Compilation(Just-in-time compilation), also knownDynamic TranslationIs a way to improve the program running efficiency. Generally, a program can run in two ways: static compilation and dynamic literal translation. Static compiled programs are all translated into machine code before execution, while literal translation is executed by running and translating one sentence at a time.

The instant compiler combines the two to compile the source code in one sentence, but caches the translated code to reduce performance consumption. Compared with static compilation code, real-time compilation code can handle delayed binding and enhance security.

There are two types of instant compilers: bytecode translation and dynamic compilation translation.

Microsoft's. NET Framework^{[1][2], there are a vast majority of Java implementations[3], all rely on instant translation to provide high-speed code execution.}

 

You can enable the hipe option for compilation in C (module, [native, {hipe, hipeoptions} | moreoptions). or add the corresponding configuration section in emakefile;

For available parameters of hipe options, we can view them through hipe: help_options (). The following is the execution result on my machine:

Erlang r14b03 (erts-5.8.4) [Source] [64-bit] [SMP: 2: 2] [RQ: 2] [async-threads: 0] [hipe] [kernel-Poll: false]

Eshell v5.8.4 (abort with ^ g)
1> hipe: help_options ().
Hipe compiler options
Boolean-valued options generally have corresponding aliases 'no _...',
And can also be specified as '{Option, true}' or '{Option, false }.

General Boolean options:
[Debug, load, pp_asm, pp_beam, pp_icode, pp_native, pp_rtl, time, timeout, verbose].

Non-Boolean options:
O #, where 0 = <# = <3:
Select optimization level (the default is 2 ).

Further options can be found below; Use 'hipe: help_option (name) 'for details.

Aliases:
Pp_all = [pp_beam, pp_icode, pp_rtl, pp_native],
Pp_iscsi = pp_native,
Pp_x86 = pp_native,
Pp_amd64 = pp_native,
Pp_ppc = pp_native,
O0,
O1 = [inline_fp, pmatch, peephole],
O2 = [icode_range, icode_ssa_const_prop, icode_ssa_copy_prop, icode_type,
Icode_inline_bifs, rtl_lcm, rtl_ssa, rtl_ssa_const_prop, spillmin_color,
Use_indexing, remove_comments, concurrent_comp, binary_opt] ++ O1,
O3 = [{regalloc, coalescing}, icode_range] ++ O2.
OK

 Note:Another option is to compile your Erlang module to native code. native code Compiling isNotAvailable for every platform and OS, but on those that support it, it can make your programs go faster (about 20% faster, based on anecdotal evister ). to compile to native code, you need to usehipeModule and call it the following way:hipe:c(Module,OptionsList).You coshould also usec(Module,[{hipe,o3}]).When in the shell to achieve similar results. Note that the. Beam file generated will no longer be portable into SS platforms like regular ones.

Enable SASL Error Log

The standard behavior of OTP sends process and error messages to error_logger (I will have a special article to explain later). We can start SASL by adding startup parameters.

Erl-boot start_sasl

After the startup, the information is output in shell. You can add the configuration to record the information to the text and view it through RB: Start; here <Erlang Program Design> has detailed examples, which will not be described here.

 

Process one-way monitoring-Monitor

The link method can establish two-way links between processes. We can use monitor to implement one-way monitoring. The corresponding example can be seen in the gen_server code.

• Erlang: Monitor (process, caller), % establish one-way monitoring
• Type of the message sent when the monitored process dies:
  {'Lowdown ', mref, process, PID, reason}
• Unmonitor: Erlang: demonitor (REF)

Gen_server code snippet:

Do_multi_call (nodes, name, req, timeout)->
Tag = make_ref (),
Caller = self (),
Extends ER =
Spawn (
Fun ()->
% Middleman process. shocould be unsensitive to regular
% Exit signals. The sychronization is needed in case
% The caller wocould exit before the caller started
% The Monitor.
Process_flag (trap_exit, true ),
Mref = Erlang: Monitor (process, caller), % establish one-way monitoring
Receive
{Caller, tag}->
Monitors = send_nodes (nodes, name, Tag, req ),
Timerid = Erlang: start_timer (timeout, self (), OK ),
Result = rec_nodes (TAG, monitors, name, timerid ),
Exit ({self (), Tag, result });
{'Lowdown ', mref, _}-> % accept monitoring messages
% Caller died before sending us the go-ahead.
% Give up silently.
Exit (normal)
End
End ),
Mref = Erlang: Monitor (process, worker ER ),
Else er! {Self (), tag },
Receive
{'Lowdown ', mref, _, _, {operator, Tag, result }}->
Result;
{'Lowdown ', mref, _, _, reason}->
% The middleman Code failed. Or someone did
% Exit (_, kill) on the middleman process => reason = killed
Exit (reason)
End.