diff options
Diffstat (limited to 'erts/doc')
| -rw-r--r-- | erts/doc/src/absform.xml | 4 | ||||
| -rw-r--r-- | erts/doc/src/erl.xml | 22 | ||||
| -rw-r--r-- | erts/doc/src/erl_nif.xml | 62 | ||||
| -rw-r--r-- | erts/doc/src/erl_tracer.xml | 146 | ||||
| -rw-r--r-- | erts/doc/src/erlang.xml | 257 | ||||
| -rw-r--r-- | erts/doc/src/erts_alloc.xml | 2 | ||||
| -rw-r--r-- | erts/doc/src/init.xml | 15 | ||||
| -rw-r--r-- | erts/doc/src/match_spec.xml | 149 | ||||
| -rw-r--r-- | erts/doc/src/notes.xml | 625 |
9 files changed, 360 insertions, 922 deletions
diff --git a/erts/doc/src/absform.xml b/erts/doc/src/absform.xml index bfabb7f042..0b04f8f70e 100644 --- a/erts/doc/src/absform.xml +++ b/erts/doc/src/absform.xml @@ -152,9 +152,11 @@ <list type="bulleted"> <item>If L is an atom literal, then Rep(L) = <c>{atom,LINE,L}</c>.</item> + <item>If L is a character literal, then + Rep(L) = <c>{char,LINE,L}</c>.</item> <item>If L is a float literal, then Rep(L) = <c>{float,LINE,L}</c>.</item> - <item>If L is an integer or character literal, then + <item>If L is an integer literal, then Rep(L) = <c>{integer,LINE,L}</c>.</item> <item>If L is a string literal consisting of the characters <c>C_1</c>, ..., <c>C_k</c>, then diff --git a/erts/doc/src/erl.xml b/erts/doc/src/erl.xml index 1bbde7f1e0..5d5bfb141f 100644 --- a/erts/doc/src/erl.xml +++ b/erts/doc/src/erl.xml @@ -338,7 +338,8 @@ <seealso marker="kernel:net_kernel">net_kernel(3)</seealso>. It is also ensured that <c><![CDATA[epmd]]></c> runs on the current host before Erlang is started. See - <seealso marker="epmd">epmd(1)</seealso>.</p> + <seealso marker="epmd">epmd(1)</seealso> and the + <seealso marker="#start_epmd"><c>-start_epmd</c></seealso> option.</p> <p>The name of the node will be <c><![CDATA[Name@Host]]></c>, where <c><![CDATA[Host]]></c> is the fully qualified host name of the current host. For short names, use the <c><![CDATA[-sname]]></c> flag instead.</p> @@ -463,6 +464,21 @@ flag and those running with the <c><![CDATA[-name]]></c> flag, as node names must be unique in distributed Erlang systems.</p> </item> + <tag><marker id="start_epmd"/><c>-start_epmd true | false</c></tag> + <item> + + <p>Specifies whether Erlang should start + <seealso marker="epmd">epmd</seealso> on startup. By default + this is <c>true</c>, but if you prefer to start epmd + manually, set this to <c>false</c>.</p> + + <p>This only applies if Erlang is started as a distributed node, + i.e. if <c>-name</c> or <c>-sname</c> is specified. Otherwise, + epmd is not started even if <c>-start_epmd true</c> is given.</p> + + <p>Note that a distributed node will fail to start if epmd is + not running.</p> + </item> <tag><marker id="smp"/><c><![CDATA[-smp [enable|auto|disable]]]></c></tag> <item> <p><c>-smp enable</c> and <c>-smp</c> starts the Erlang runtime @@ -660,11 +676,11 @@ <p>Sets the initial process dictionary size of processes to the size <c><![CDATA[Size]]></c>.</p> </item> - <tag><marker id="+hmqd"><c>+hmqd off_heap|on_heap|mixed</c></marker></tag> + <tag><marker id="+hmqd"><c>+hmqd off_heap|on_heap</c></marker></tag> <item><p> Sets the default value for the process flag <c>message_queue_data</c>. If <c>+hmqd</c> is not - passed, <c>mixed</c> will be the default. For more information, + passed, <c>on_heap</c> will be the default. For more information, see the documentation of <seealso marker="erlang#process_flag_message_queue_data"><c>process_flag(message_queue_data, MQD)</c></seealso>. diff --git a/erts/doc/src/erl_nif.xml b/erts/doc/src/erl_nif.xml index fefec3eeb6..123d353432 100644 --- a/erts/doc/src/erl_nif.xml +++ b/erts/doc/src/erl_nif.xml @@ -295,14 +295,14 @@ ok </p></item> <tag><marker id="time_measurement"/>Time Measurement</tag> - <item><p>Support for time measurement in NIF libraries: + <item><p>Support for time measurement in NIF libraries:</p> <list> <item><seealso marker="#ErlNifTime"><c>ErlNifTime</c></seealso></item> <item><seealso marker="#ErlNifTimeUnit"><c>ErlNifTimeUnit</c></seealso></item> <item><seealso marker="#enif_monotonic_time"><c>enif_monotonic_time()</c></seealso></item> <item><seealso marker="#enif_time_offset"><c>enif_time_offset()</c></seealso></item> <item><seealso marker="#enif_convert_time_unit"><c>enif_convert_time_unit()</c></seealso></item> - </list></p> + </list> </item> <tag><marker id="lengthy_work"/>Long-running NIFs</tag> @@ -322,13 +322,13 @@ ok <p>The <seealso marker="#enif_consume_timeslice">enif_consume_timeslice()</seealso> - function can be used to inform the runtime system about the lenght of the + function can be used to inform the runtime system about the length of the NIF call. It should typically always be used unless the NIF executes very quickly.</p> - <p>If the NIF call is too lenghty one needs to handle this in one of the + <p>If the NIF call is too lengthy one needs to handle this in one of the following ways in order to avoid degraded responsiveness, scheduler load - balancing problems, and other strange behaviours:</p> + balancing problems, and other strange behaviors:</p> <taglist> <tag>Yielding NIF</tag> @@ -410,14 +410,14 @@ ok <seealso marker="erlang#system_flag_multi_scheduling"><c>erlang:system_flag(multi_scheduling, block)</c></seealso>, might also take a very long time to complete. This since all ongoing dirty operations on all - dirty schedulers need to complete before the the block + dirty schedulers need to complete before the block operation can complete. </p> <p> A lot of operations communicating with a process executing a dirty NIF can, however, complete while it is executing the - dirty NIF. For example, retreiving information about it via + dirty NIF. For example, retrieving information about it via <c>process_info()</c>, setting its group leader, register/unregister its name, etc. </p> @@ -425,10 +425,10 @@ ok <p> Termination of a process executing a dirty NIF can only be completed up to a certain point while it is executing the - dirty NIF. All Erlang resources such as registered names, - ETS tables, etc will be released. All links and monitors + dirty NIF. All Erlang resources such as its registered name, + its ETS tables, etc will be released. All links and monitors will be triggered. The actual execution of the NIF will - however <em>not</em> be stopped. The NIF can safely contiue + however <em>not</em> be stopped. The NIF can safely continue execution, allocate heap memory, etc, but it is of course better to stop executing as soon as possible. The NIF can check whether current process is alive or not using @@ -450,8 +450,8 @@ ok collect a process in order to determine if it has references to the module, a process executing a dirty NIF might delay purging for a very long time. Delaying - a purge operatin implies delaying <em>all</em> code - loding operations which might cause severe problems for + a purge operation implies delaying <em>all</em> code + loading operations which might cause severe problems for the system as a whole. </p> </item> @@ -1101,15 +1101,6 @@ typedef enum { Erlang operators <c>=:=</c> and <c>=/=</c>.</p></desc> </func> - <func><name><ret>int</ret><nametext>enif_is_on_dirty_scheduler(ErlNifEnv* env)</nametext></name> - <fsummary>Check to see if executing on a dirty scheduler thread</fsummary> - <desc> - <p>Check to see if the current NIF is executing on a dirty scheduler thread. If - executing on a dirty scheduler thread true returned; otherwise false.</p> - <p>This function can only be used from a NIF-calling thread, and with an - environment corresponding to currently executing processes.</p> - </desc> - </func> <func><name><ret>int</ret><nametext>enif_is_pid(ErlNifEnv* env, ERL_NIF_TERM term)</nametext></name> <fsummary>Determine if a term is a pid</fsummary> <desc><p>Return true if <c>term</c> is a pid.</p></desc> @@ -1763,6 +1754,15 @@ enif_map_iterator_destroy(env, &iter); <desc><p>Get the byte size of a resource object <c>obj</c> obtained by <seealso marker="#enif_alloc_resource">enif_alloc_resource</seealso>.</p></desc> </func> + + <func><name><ret>int</ret><nametext>enif_snprintf(char *str, size_t size, const char *format, ...)</nametext></name> + <fsummary>Format strings and Erlang terms</fsummary> + <desc> + <p>Similar to <c>snprintf</c> but this format string also accepts <c>"%T"</c> which formats Erlang terms. + </p> + </desc> + </func> + <func> <name><ret>void</ret><nametext>enif_system_info(ErlNifSysInfo *sys_info_ptr, size_t size)</nametext></name> <fsummary>Get information about the Erlang runtime system</fsummary> @@ -1811,7 +1811,25 @@ enif_map_iterator_destroy(env, &iter); <desc><p>Same as <seealso marker="erl_driver#erl_drv_thread_self">erl_drv_thread_self</seealso>. </p></desc> </func> - + <func><name><ret>int</ret><nametext>enif_thread_type(void)</nametext></name> + <fsummary>Determine type of current thread</fsummary> + <desc> + <p>Determine the type of currently executing thread. A positive value + indicates a scheduler thread while a negative value or zero indicates + another type of thread. Currently the following specific types exist + (which may be extended in the future):</p> + <taglist> + <tag><c>ERL_NIF_THR_UNDEFINED</c></tag> + <item><p>Undefined thread that is not a scheduler thread.</p></item> + <tag><c>ERL_NIF_THR_NORMAL_SCHEDULER</c></tag> + <item><p>A normal scheduler thread.</p></item> + <tag><c>ERL_NIF_THR_DIRTY_CPU_SCHEDULER</c></tag> + <item><p>A dirty CPU scheduler thread.</p></item> + <tag><c>ERL_NIF_THR_DIRTY_IO_SCHEDULER</c></tag> + <item><p>A dirty I/O scheduler thread.</p></item> + </taglist> + </desc> + </func> <func> <name><ret>ErlNifTime</ret><nametext>enif_time_offset(ErlNifTimeUnit time_unit)</nametext></name> <fsummary>Get current Time Offset</fsummary> diff --git a/erts/doc/src/erl_tracer.xml b/erts/doc/src/erl_tracer.xml index 7fd5512b33..7841fdfd63 100644 --- a/erts/doc/src/erl_tracer.xml +++ b/erts/doc/src/erl_tracer.xml @@ -67,7 +67,7 @@ <desc> <p>The different trace tags that the tracer will be called with. Each trace tag is described in greater detail in - <seealso marker="#trace">Module:trace/6</seealso> + <seealso marker="#Module:trace/5">Module:trace/5</seealso> </p> </desc> </datatype> @@ -81,19 +81,22 @@ <datatype> <name name="trace_opts" /> <desc> - <p>The options for the tracee. + <p>The options for the tracee.</p> <taglist> <tag><c>timestamp</c></tag> - <item>If not set to <c>undefined</c>, the tracer has been requested to - include a timestamp.</item> + <item>If set the tracer has been requested to include a timestamp.</item> + <tag><c>extra</c></tag> + <item>If set the tracepoint has included additonal data about + the trace event. What the additional data is depends on which + <c>TraceTag</c> has been triggered. The <c>extra</c> trace data + corresponds to the fifth elemnt in the trace tuples described in + <seealso marker="erlang#trace_3_trace_messages">erlang:trace/3</seealso>.</item> <tag><c>match_spec_result</c></tag> - <item>If not set to <c>true</c>, the tracer has been requested to - include the output of a match specification that was run.</item> + <item>If set the tracer has been requested to include the output + of a match specification that was run.</item> <tag><c>scheduler_id</c></tag> - <item>Set to a number if the scheduler id is to be included by the tracer. - Otherwise it is set to <c>undefined</c>.</item> + <item>Set the scheduler id is to be included by the tracer.</item> </taglist> - </p> </desc> </datatype> <datatype> @@ -114,30 +117,30 @@ <p>The following functions should be exported from a <c>erl_tracer</c> callback module.</p> <taglist> - <tag><seealso marker="#enabled"><c>Module:enabled/3</c></seealso></tag> + <tag><seealso marker="#Module:enabled/3"><c>Module:enabled/3</c></seealso></tag> <item>Mandatory</item> - <tag><seealso marker="#trace"><c>Module:trace/6</c></seealso></tag> + <tag><seealso marker="#Module:trace/5"><c>Module:trace/5</c></seealso></tag> <item>Mandatory</item> - <tag><seealso marker="#enabled_procs"><c>Module:enabled_procs/3</c></seealso></tag> + <tag><seealso marker="#Module:enabled_procs/3"><c>Module:enabled_procs/3</c></seealso></tag> <item>Optional</item> - <tag><seealso marker="#trace_procs"><c>Module:trace_procs/6</c></seealso></tag> + <tag><seealso marker="#Module:trace_procs/5"><c>Module:trace_procs/5</c></seealso></tag> <item>Optional</item> - <tag><seealso marker="#enabled_ports"><c>Module:enabled_ports/3</c></seealso></tag> + <tag><seealso marker="#Module:enabled_ports/3"><c>Module:enabled_ports/3</c></seealso></tag> <item>Optional</item> - <tag><seealso marker="#trace_ports"><c>Module:trace_ports/6</c></seealso></tag> + <tag><seealso marker="#Module:trace_ports/5"><c>Module:trace_ports/5</c></seealso></tag> <item>Optional</item> - <tag><seealso marker="#enabled_running_ports"><c>Module:enabled_running_ports/3</c></seealso></tag> + <tag><seealso marker="#Module:enabled_running_ports/3"><c>Module:enabled_running_ports/3</c></seealso></tag> <item>Optional</item> - <tag><seealso marker="#trace_running_ports"><c>Module:trace_running_ports/6</c></seealso></tag> + <tag><seealso marker="#Module:trace_running_ports/5"><c>Module:trace_running_ports/5</c></seealso></tag> <item>Optional</item> - <tag><seealso marker="#enabled_running_procs"><c>Module:enabled_running_procs/3</c></seealso></tag> + <tag><seealso marker="#Module:enabled_running_procs/3"><c>Module:enabled_running_procs/3</c></seealso></tag> <item>Optional</item> - <tag><seealso marker="#trace_running_procs"><c>Module:trace_running_procs/6</c></seealso></tag> + <tag><seealso marker="#Module:trace_running_procs/5"><c>Module:trace_running_procs/5</c></seealso></tag> <item>Optional</item> </taglist> </section> - <marker id="enabled"></marker> + <funcs> <func> <name>Module:enabled(TraceTag, TracerState, Tracee) -> Result</name> @@ -166,35 +169,33 @@ is important that it is both fast and side effect free.</p> </desc> </func> - <marker id="trace"></marker> <func> - <name>Module:trace(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag">trace_tag()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled">Module:enabled/3</seealso> + the <seealso marker="#Module:enabled/3">Module:enabled/3</seealso> callback returned <c>trace</c>. In it any side effects needed by the tracer should be done. The tracepoint payload is located in - the <c>FirstTraceTerm</c> and <c>SecondTraceTerm</c>. The content - of the TraceTerms depends on which <c>TraceTag</c> has been triggered. - The <c>FirstTraceTerm</c> and <c>SecondTraceTerm</c> correspond to the - fourth and fifth slot in the trace tuples described in + the <c>TraceTerm</c>. The content of the TraceTerm depends on which + <c>TraceTag</c> has been triggered. + The <c>TraceTerm</c> corresponds to the + fourth element in the trace tuples described in <seealso marker="erlang#trace_3_trace_messages">erlang:trace/3</seealso>. - If the tuple only has four elements, <c>SecondTraceTerm</c> will be - <c>undefined</c>.</p> + If the trace tuple has five elements, the fifth element will be sent as + the <c>extra</c> value in the <c>Opts</c> maps.</p> </desc> </func> <func> - <name name="trace">Module:trace(seq_trace, TracerState, Label, SeqTraceInfo, undefined, Opts) -> Result</name> + <name name="trace">Module:trace(seq_trace, TracerState, Label, SeqTraceInfo, Opts) -> Result</name> <fsummary>Check if a sequence trace event should be generated.</fsummary> <type> <v>TracerState = term()</v> @@ -212,7 +213,6 @@ </desc> </func> - <marker id="enabled_procs"></marker> <func> <name>Module:enabled_procs(TraceTag, TracerState, Tracee) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> @@ -230,28 +230,25 @@ </desc> </func> - <marker id="trace_procs"></marker> <func> - <name>Module:trace_procs(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace_procs(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag_procs">trace_tag()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled_procs">Module:enabled_procs/3</seealso> + the <seealso marker="#Module:enabled_procs/3">Module:enabled_procs/3</seealso> callback returned <c>trace</c>.</p> - <p>If <c>trace_procs/6</c> is not defined <c>trace/6</c> will be called instead.</p> + <p>If <c>trace_procs/5</c> is not defined <c>trace/5</c> will be called instead.</p> </desc> </func> - <marker id="enabled_ports"></marker> <func> <name>Module:enabled_ports(TraceTag, TracerState, Tracee) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> @@ -269,28 +266,25 @@ </desc> </func> - <marker id="trace_ports"></marker> <func> - <name>Module:trace_ports(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace_ports(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag_ports">trace_tag()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled_ports">Module:enabled_ports/3</seealso> + the <seealso marker="#Module:enabled_ports/3">Module:enabled_ports/3</seealso> callback returned <c>trace</c>.</p> - <p>If <c>trace_ports/6</c> is not defined <c>trace/6</c> will be called instead.</p> + <p>If <c>trace_ports/5</c> is not defined <c>trace/5</c> will be called instead.</p> </desc> </func> - <marker id="enabled_running_procs"></marker> <func> <name>Module:enabled_running_procs(TraceTag, TracerState, Tracee) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> @@ -308,28 +302,25 @@ </desc> </func> - <marker id="trace_running_procs"></marker> <func> - <name>Module:trace_running_procs(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace_running_procs(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag_running_procs">trace_tag_running_procs()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled_running_procs">Module:enabled_running_procs/3</seealso> + the <seealso marker="#Module:enabled_running_procs/3">Module:enabled_running_procs/3</seealso> callback returned <c>trace</c>.</p> - <p>If <c>trace_running_procs/6</c> is not defined <c>trace/6</c> will be called instead.</p> + <p>If <c>trace_running_procs/5</c> is not defined <c>trace/5</c> will be called instead.</p> </desc> </func> - <marker id="enabled_running_ports"></marker> <func> <name>Module:enabled_running_ports(TraceTag, TracerState, Tracee) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> @@ -347,28 +338,25 @@ </desc> </func> - <marker id="trace_running_ports"></marker> <func> - <name>Module:trace_running_ports(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace_running_ports(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag_running_ports">trace_tag_running_ports()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled_running_ports">Module:enabled_running_ports/3</seealso> + the <seealso marker="#Module:enabled_running_ports/3">Module:enabled_running_ports/3</seealso> callback returned <c>trace</c>.</p> - <p>If <c>trace_running_ports/6</c> is not defined <c>trace/6</c> will be called instead.</p> + <p>If <c>trace_running_ports/5</c> is not defined <c>trace/5</c> will be called instead.</p> </desc> </func> - <marker id="enabled_call"></marker> <func> <name>Module:enabled_call(TraceTag, TracerState, Tracee) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> @@ -386,28 +374,25 @@ </desc> </func> - <marker id="trace_call"></marker> <func> - <name>Module:trace_call(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace_call(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag_call">trace_tag_call()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled_call">Module:enabled_call/3</seealso> + the <seealso marker="#Module:enabled_call/3">Module:enabled_call/3</seealso> callback returned <c>trace</c>.</p> - <p>If <c>trace_call/6</c> is not defined <c>trace/6</c> will be called instead.</p> + <p>If <c>trace_call/5</c> is not defined <c>trace/5</c> will be called instead.</p> </desc> </func> - <marker id="enabled_send"></marker> <func> <name>Module:enabled_send(TraceTag, TracerState, Tracee) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> @@ -425,28 +410,25 @@ </desc> </func> - <marker id="trace_send"></marker> <func> - <name>Module:trace_send(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace_send(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag_send">trace_tag_send()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled_send">Module:enabled_send/3</seealso> + the <seealso marker="#Module:enabled_send/3">Module:enabled_send/3</seealso> callback returned <c>trace</c>.</p> - <p>If <c>trace_send/6</c> is not defined <c>trace/6</c> will be called instead.</p> + <p>If <c>trace_send/5</c> is not defined <c>trace/5</c> will be called instead.</p> </desc> </func> - <marker id="enabled_receive"></marker> <func> <name>Module:enabled_receive(TraceTag, TracerState, Tracee) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> @@ -464,28 +446,25 @@ </desc> </func> - <marker id="trace_receive"></marker> <func> - <name>Module:trace_receive(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace_receive(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag_receive">trace_tag_receive()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled_receive">Module:enabled_receive/3</seealso> + the <seealso marker="#Module:enabled_receive/3">Module:enabled_receive/3</seealso> callback returned <c>trace</c>.</p> - <p>If <c>trace_receive/6</c> is not defined <c>trace/6</c> will be called instead.</p> + <p>If <c>trace_receive/5</c> is not defined <c>trace/5</c> will be called instead.</p> </desc> </func> - <marker id="enabled_garbage_collection"></marker> <func> <name>Module:enabled_garbage_collection(TraceTag, TracerState, Tracee) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> @@ -503,24 +482,22 @@ </desc> </func> - <marker id="trace_garbage_collection"></marker> <func> - <name>Module:trace_garbage_collection(TraceTag, TracerState, Tracee, FirstTraceTerm, SecondTraceTerm, Opts) -> Result</name> + <name>Module:trace_garbage_collection(TraceTag, TracerState, Tracee, TraceTerm, Opts) -> Result</name> <fsummary>Check if a trace event should be generated.</fsummary> <type> <v>TraceTag = <seealso marker="#type-trace_tag_gc">trace_tag_gc()</seealso></v> <v>TracerState = term()</v> <v>Tracee = <seealso marker="#type-tracee">tracee()</seealso></v> <v>FirstTraceTerm = term()</v> - <v>SecondTraceTerm = term() | undefined</v> <v>Opts = <seealso marker="#type-trace_opts">trace_opts()</seealso></v> <v>Result = ok</v> </type> <desc> <p>This callback will be called when a tracepoint is triggered and - the <seealso marker="#enabled_garbage_collection">Module:enabled_garbage_collection/3</seealso> + the <seealso marker="#Module:enabled_garbage_collection/3">Module:enabled_garbage_collection/3</seealso> callback returned <c>trace</c>.</p> - <p>If <c>trace_garbage_collection/6</c> is not defined <c>trace/6</c> will be called instead.</p> + <p>If <c>trace_garbage_collection/5</c> is not defined <c>trace/5</c> will be called instead.</p> </desc> </func> @@ -561,7 +538,7 @@ ok <pre> -module(erl_msg_tracer). --export([enabled/3, trace/6, load/0]). +-export([enabled/3, trace/5, load/0]). load() -> erlang:load_nif("erl_msg_tracer", []). @@ -569,7 +546,7 @@ load() -> enabled(_, _, _) -> error. -trace(_, _, _,_, _, _) -> +trace(_, _, _,_, _) -> error. </pre> <p>erl_msg_tracer.c</p> @@ -587,7 +564,7 @@ static ERL_NIF_TERM trace(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]); static ErlNifFunc nif_funcs[] = { {"enabled", 3, enabled}, - {"trace", 6, trace} + {"trace", 5, trace} }; ERL_NIF_INIT(erl_msg_tracer, nif_funcs, load, NULL, upgrade, unload) @@ -650,9 +627,8 @@ static ERL_NIF_TERM enabled(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) * argv[0]: TraceTag, should only be 'send' * argv[1]: TracerState, process to send {argv[2], argv[4]} to * argv[2]: Tracee - * argv[3]: Message, ignored - * argv[4]: Recipient - * argv[5]: Options, ignored + * argv[3]: Recipient + * argv[4]: Options, ignored */ static ERL_NIF_TERM trace(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml index e0723127f2..fa13e4c142 100644 --- a/erts/doc/src/erlang.xml +++ b/erts/doc/src/erlang.xml @@ -52,7 +52,6 @@ <datatype> <name>ext_binary()</name> <desc> - <marker id="type-ext_binary"></marker> <p>A binary data object, structured according to the Erlang external term format.</p> </desc> @@ -1803,6 +1802,8 @@ os_prompt% </pre> <tag>string()</tag> <item>An Erlang crash dump is produced with <c><anno>Status</anno></c> as slogan. Then the runtime system exits with status code <c>1</c>. + Note that only code points in the range 0-255 may be used + and the string will be truncated if longer than 200 characters. </item> <tag><c>abort</c></tag> <item> @@ -2915,107 +2916,105 @@ os_prompt% </pre> <func> <name name="monitor" arity="2" clause_i="1"/> <name name="monitor" arity="2" clause_i="2"/> + <name name="monitor" arity="2" clause_i="3"/> <fsummary>Starts monitoring.</fsummary> <type name="registered_name"/> <type name="registered_process_identifier"/> <type name="monitor_process_identifier"/> + <type name="monitor_port_identifier"/> <desc> - <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> + <p>Sends a monitor request of type <c><anno>Type</anno></c> to the + entity identified by <c><anno>Item</anno></c>. If the monitored entity + does not exist or when it dies, the caller of <c>monitor/2</c> will + be notified by a message on the following format:</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 reaches its destination.</p></note> - <p>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>. Valid - <c><anno>Item</anno></c>s in combination with the - <c>process <anno>Type</anno></c> can be any of the following:</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 registered name is used, the - process that has the registered name when the - monitor request reach its destination will be monitored. - The monitor is not effected if the registered name is - 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 is - 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>Here <c>MonitorRef</c> and <c>Type</c> are the same as - described earlier, 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> is specified by a - process identifier.</item> - <tag><c>{RegisteredName, Node}</c></tag> - <item>If <c><anno>Item</anno></c> is 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 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 - 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 ERTS - version 5.2 (OTP R9B) for monitoring - <em>by registered name</em>. Element <c>Object</c> of - the <c>'DOWN'</c> message could in earlier versions - sometimes be the process identifier of the monitored process and sometimes - be the registered name. Now element <c>Object</c> is - always a tuple consisting of the registered name and - the node name. Processes on new nodes (ERTS version 5.2 - or higher) always get <c>'DOWN'</c> messages on - the new format even if they are monitoring processes on old - nodes. Processes on old nodes always get <c>'DOWN'</c> - messages on the old format.</p> - </note> - </item> - <tag><marker id="monitor_time_offset"/><c>time_offset</c></tag> + + <p><c><anno>Type</anno></c> can be one of the following atoms: + <c>process</c>, <c>port</c> or <c>time_offset</c>.</p> + + <p>A monitor is triggered only once, after that it is removed from + both monitoring process and the monitored entity. + Monitors are fired when the monitored process or port terminates, + does not exist at the moment of creation, or if the connection to + it is lost. In the case with connection, we lose knowledge about + the fact if it still exists or not. The monitoring is also turned off + when <seealso marker="#demonitor/1">demonitor/1</seealso> + is called.</p> + + <p>When monitoring by name please note, that the <c>RegisteredName</c> + is resolved to <c>pid()</c> or <c>port()</c> only once + at the moment of monitor instantiation, later changes to the name + registration will not affect the existing monitor.</p> + + <p>When a monitor is triggered, a <c>'DOWN'</c> message that has the + following pattern <c>{'DOWN', MonitorRef, Type, Object, Info}</c> + is sent to the monitoring process.</p> + + <p>In monitor message <c>MonitorRef</c> and <c>Type</c> are the same as + described earlier, and:</p> + <taglist> + <tag><c>Object</c></tag> + <item> + <p>The monitored entity, which triggered the event. When monitoring + a local process or port, <c>Object</c> will be equal to the + <c>pid()</c> or <c>port()</c> that was being monitored. When + monitoring process or port by name, <c>Object</c> will have format + <c>{RegisteredName, Node}</c> where <c>RegisteredName</c> is the + name which has been used with <c>monitor/2</c> call and + <c>Node</c> is local or remote node name (for ports monitored by + name, <c>Node</c> is always local node name).</p> + </item> + <tag><c>Info</c></tag> + <item> + <p>Either the exit reason of the process, <c>noproc</c> + (process or port did not exist at the time of monitor creation), + or <c>noconnection</c> (no connection to the node where the + monitored process resides). </p></item> + </taglist> + + <p>If an attempt is made to monitor a process on an older node + (where remote process monitoring is not implemented or + 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 ERTS + version 5.2 (OTP R9B) for monitoring + <em>by registered name</em>. Element <c>Object</c> of + the <c>'DOWN'</c> message could in earlier versions + sometimes be the process identifier of the monitored process and sometimes + be the registered name. Now element <c>Object</c> is + always a tuple consisting of the registered name and + the node name. Processes on new nodes (ERTS version 5.2 + or higher) always get <c>'DOWN'</c> messages on + the new format even if they are monitoring processes on old + nodes. Processes on old nodes always get <c>'DOWN'</c> + messages on the old format.</p> + </note> + + <taglist> + <tag>Monitoring a <marker id="monitor_process"/><c>process</c></tag> + <item> + <p>Creates monitor between the current process and another + process identified by <c><anno>Item</anno></c>, which can be a + <c>pid()</c> (local or remote), an atom <c>RegisteredName</c> or + a tuple <c>{RegisteredName, Node}</c> for a registered process, + located elsewhere.</p> + </item> + + <tag>Monitoring a <marker id="monitor_port"/><c>port</c></tag> + <item> + <p>Creates monitor between the current process and a port + identified by <c><anno>Item</anno></c>, which can be a + <c>port()</c> (only local), an atom <c>RegisteredName</c> or + a tuple <c>{RegisteredName, Node}</c> for a registered port, + located on this node. Note, that attempt to monitor a remote port + will result in <c>badarg</c>.</p> + </item> + + <tag>Monitoring a + <marker id="monitor_time_offset"/><c>time_offset</c></tag> <item> <p>Monitor changes in <seealso marker="#time_offset/0">time offset</seealso> @@ -3071,15 +3070,17 @@ os_prompt% </pre> Note that you can 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 as many independent monitoring instances.</p> + <c><anno>Item</anno></c> and/or <c><anno>Type</anno></c> is not + an error; it results in as many independent monitoring instances.</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 a future release.</p> + other <c><anno>Type</anno></c>s and <c><anno>Item</anno></c>s + are expected to be supported in a future release.</p> + <note> <p>If or when <c>monitor/2</c> is extended, other possible values for <c>Tag</c>, <c>Object</c> and @@ -4149,6 +4150,22 @@ os_prompt% </pre> <func> <name name="port_info" arity="2" clause_i="8"/> + <fsummary>Which processes are monitoring this port.</fsummary> + <desc> + <p>Returns list of pids that are monitoring given port at the + moment.</p> + <p>If the port identified by <c><anno>Port</anno></c> is not open, + <c>undefined</c> is returned. If the port is closed and the + calling process was previously linked to the port, the exit + signal from the port is guaranteed to be delivered before + <c>port_info/2</c> returns <c>undefined</c>.</p> + <p>Failure: <c>badarg</c> if <c><anno>Port</anno></c> is not a local + port identifier, or an atom.</p> + </desc> + </func> + + <func> + <name name="port_info" arity="2" clause_i="9"/> <fsummary>Information about the name of a port.</fsummary> <desc> <p><c><anno>Name</anno></c> is the command name set by @@ -4164,7 +4181,7 @@ os_prompt% </pre> </func> <func> - <name name="port_info" arity="2" clause_i="9"/> + <name name="port_info" arity="2" clause_i="10"/> <fsummary>Information about the OS pid of a port.</fsummary> <desc> <p><c><anno>OsPid</anno></c> is the process identifier (or equivalent) @@ -4183,7 +4200,7 @@ os_prompt% </pre> </func> <func> - <name name="port_info" arity="2" clause_i="10"/> + <name name="port_info" arity="2" clause_i="11"/> <fsummary>Information about the output of a port.</fsummary> <desc> <p><c><anno>Bytes</anno></c> is the total number of bytes written @@ -4202,7 +4219,7 @@ os_prompt% </pre> </func> <func> - <name name="port_info" arity="2" clause_i="11"/> + <name name="port_info" arity="2" clause_i="12"/> <fsummary>Information about the parallelism hint of a port.</fsummary> <desc> <p><c><anno>Boolean</anno></c> corresponds to the port parallelism @@ -4213,7 +4230,7 @@ os_prompt% </pre> </func> <func> - <name name="port_info" arity="2" clause_i="12"/> + <name name="port_info" arity="2" clause_i="13"/> <fsummary>Information about the queue size of a port.</fsummary> <desc> <p><c><anno>Bytes</anno></c> is the total number @@ -4230,7 +4247,7 @@ os_prompt% </pre> </func> <func> - <name name="port_info" arity="2" clause_i="13"/> + <name name="port_info" arity="2" clause_i="14"/> <fsummary>Information about the registered name of a port.</fsummary> <desc> <p><c><anno>RegisteredName</anno></c> is the registered name of @@ -4450,11 +4467,6 @@ os_prompt% </pre> off heap. This is how messages always have been stored up until ERTS version 8.0. </p></item> - <tag><c>mixed</c></tag> - <item><p> - Messages may be placed either on the heap or outside - of the heap. - </p></item> </taglist> <p> The default <c>message_queue_data</c> process flag is determined @@ -4869,16 +4881,25 @@ os_prompt% </pre> <p>A list of monitors (started by <c>monitor/2</c>) that are active for the process. For a local process monitor or a remote process monitor by a process - identifier, the list item is <c>{process, <anno>Pid</anno>}</c>. - For a remote process - monitor by name, the list item is - <c>{process, {<anno>RegName</anno>, <anno>Node</anno>}}</c>.</p> + identifier, the list consists of:</p> + <taglist> + <tag><c>{process, <anno>Pid</anno>}</c></tag> + <item>Process is monitored by pid.</item> + <tag><c>{process, {<anno>RegName</anno>, <anno>Node</anno>}}</c></tag> + <item>Local or remote process is monitored by name.</item> + <tag><c>{port, PortId}</c></tag> + <item>Local port is monitored by port id.</item> + <tag><c>{port, {<anno>RegName</anno>, <anno>Node</anno>}}</c></tag> + <item>Local port is monitored by name. Please note, that + remote port monitors are not supported, so <c>Node</c> will + always be the local node name.</item> + </taglist> </item> <tag><c>{message_queue_data, <anno>MQD</anno>}</c></tag> <item> <p>Returns the current state of the <c>message_queue_data</c> process flag. <c><anno>MQD</anno></c> is either <c>off_heap</c>, - <c>on_heap</c>, or <c>mixed</c>. For more information, see the + or <c>on_heap</c>. For more information, see the documentation of <seealso marker="#process_flag_message_queue_data"><c>process_flag(message_queue_data, MQD)</c></seealso>.</p> @@ -5070,10 +5091,6 @@ os_prompt% </pre> <p>Stops the execution of the calling process with an exception of given class, reason, and call stack backtrace (<em>stacktrace</em>).</p> - <warning> - <p>This BIF is intended for debugging. Avoid to use it in applications, - unless you really know what you are doing.</p> - </warning> <p><c><anno>Class</anno></c> is <c>error</c>, <c>exit</c>, or <c>throw</c>. So, if it were not for the stacktrace, <c>erlang:raise(<anno>Class</anno>, <anno>Reason</anno>, @@ -5813,7 +5830,7 @@ true</pre> <item> <p>Sets the state of the <c>message_queue_data</c> process flag. <c><anno>MQD</anno></c> should be either <c>off_heap</c>, - <c>on_heap</c>, or <c>mixed</c>. The default + or <c>on_heap</c>. The default <c>message_queue_data</c> process flag is determined by the <seealso marker="erl#+hmqd"><c>+hmqd</c></seealso> <c>erl</c> command line argument. For more information, see the @@ -7169,7 +7186,7 @@ ok <tag><marker id="system_info_message_queue_data"><c>message_queue_data</c></marker></tag> <item> <p>Returns the default value of the <c>message_queue_data</c> - process flag which is either <c>off_heap</c>, <c>on_heap</c>, or <c>mixed</c>. + process flag which is either <c>off_heap</c>, or <c>on_heap</c>. This default is set by the <c>erl</c> command line argument <seealso marker="erl#+hmqd"><c>+hmqd</c></seealso>. For more information on the <c>message_queue_data</c> process flag, see documentation of diff --git a/erts/doc/src/erts_alloc.xml b/erts/doc/src/erts_alloc.xml index 70775b9f0f..9aef1c0b1f 100644 --- a/erts/doc/src/erts_alloc.xml +++ b/erts/doc/src/erts_alloc.xml @@ -583,7 +583,7 @@ </taglist> <p>The following flag is special for <c>exec_alloc</c>:</p> <taglist> - <tag><marker id="MIscs"/><c><![CDATA[+MXscs <size in MB>]]></c></tag> + <tag><marker id="MXscs"/><c><![CDATA[+MXscs <size in MB>]]></c></tag> <item> <c>exec_alloc</c> super carrier size (in MB). The amount of <em>virtual</em> address space reserved for native executable code diff --git a/erts/doc/src/init.xml b/erts/doc/src/init.xml index 84a5aea335..a88a815ef6 100644 --- a/erts/doc/src/init.xml +++ b/erts/doc/src/init.xml @@ -178,14 +178,8 @@ <name name="stop" arity="0"/> <fsummary>Take down an Erlang node smoothly</fsummary> <desc> - <p>All applications are taken down smoothly, all code is - unloaded, and all ports are closed before the system - terminates. If the <c>-heart</c> command line flag was given, - the <c>heart</c> program is terminated before the Erlang node - terminates. Refer to <c>heart(3)</c> for more information.</p> - <p>To limit the shutdown time, the time <c>init</c> is allowed - to spend taking down applications, the <c>-shutdown_time</c> - command line flag should be used.</p> + <p>The same as + <seealso marker="#stop/1"><c>stop(0)</c></seealso>.</p> </desc> </func> <func> @@ -241,6 +235,11 @@ marker="kernel:code">code(3)</seealso>.</p> </item> + <tag><c>-epmd_module Module</c></tag> + <item> + <p>Specifies the module to use for registration and lookup of + node names. Defaults to <c>erl_epmd</c>.</p> + </item> <tag><c>-eval Expr</c></tag> <item> <p>Scans, parses and evaluates an arbitrary expression diff --git a/erts/doc/src/match_spec.xml b/erts/doc/src/match_spec.xml index 3944f24f84..7be3d15de6 100644 --- a/erts/doc/src/match_spec.xml +++ b/erts/doc/src/match_spec.xml @@ -33,21 +33,15 @@ <file>match_spec.xml</file> </header> <p>A "match specification" (match_spec) is an Erlang term describing a - small "program" that will try to match something (either the - parameters to a function as used in the <c><![CDATA[erlang:trace_pattern/2]]></c> - BIF, or the objects in an ETS table.). + small "program" that will try to match something. It can be used + to either control tracing with + <seealso marker="erlang#trace_pattern/3">erlang:trace_pattern/3</seealso> + or to search for objects in an ETS table with for example + <seealso marker="stdlib:ets#select/2">ets:select/2</seealso>. The match_spec in many ways works like a small function in Erlang, but is interpreted/compiled by the Erlang runtime system to something much more efficient than calling an Erlang function. The match_spec is also very limited compared to the expressiveness of real Erlang functions.</p> - <p>Match specifications are given to the BIF <c><![CDATA[erlang:trace_pattern/2]]></c> to - execute matching of function arguments as well as to define some actions - to be taken when the match succeeds (the <c><![CDATA[MatchBody]]></c> part). Match - specifications can also be used in ETS, to specify objects to be - returned from an <c><![CDATA[ets:select/2]]></c> call (or other select - calls). The semantics and restrictions differ slightly when using - match specifications for tracing and in ETS, the differences are - defined in a separate paragraph below.</p> <p>The most notable difference between a match_spec and an Erlang fun is of course the syntax. Match specifications are Erlang terms, not Erlang code. A match_spec also has a somewhat strange concept of @@ -382,6 +376,51 @@ the pid() of the current process.</p> </section> + <marker id="match_target"></marker> + <section> + <title>Match target</title> + <p>Each execution of a match specification is done against + a match target term. The format and content of the target term + depends on the context in which the match is done. The match + target for ETS is always a full table tuple. The match target + for call trace is always a list of all function arguments. The + match target for event trace depends on the event type, see + table below.</p> + <table> + <row> + <cell align="left" valign="middle">Context</cell> + <cell align="left" valign="middle">Type</cell> + <cell align="left" valign="middle">Match target</cell> + <cell align="left" valign="middle">Description</cell> + </row> + <row> + <cell align="left" valign="middle">ETS</cell> + <cell align="left" valign="middle"></cell> + <cell align="left" valign="middle">{Key, Value1, Value2, ...}</cell> + <cell align="left" valign="middle">A table object</cell> + </row> + <row> + <cell align="left" valign="middle">Trace</cell> + <cell align="left" valign="middle">call</cell> + <cell align="left" valign="middle">[Arg1, Arg2, ...]</cell> + <cell align="left" valign="middle">Function arguments</cell> + </row> + <row> + <cell align="left" valign="middle">Trace</cell> + <cell align="left" valign="middle">send</cell> + <cell align="left" valign="middle">[Receiver, Message]</cell> + <cell align="left" valign="middle">Receiving process/port and message term</cell> + </row> + <row> + <cell align="left" valign="middle">Trace</cell> + <cell align="left" valign="middle">'receive'</cell> + <cell align="left" valign="middle">[Node, Sender, Message]</cell> + <cell align="left" valign="middle">Sending node, process/port and message term</cell> + </row> + <tcaption>Match target depending on context</tcaption> + </table> + </section> + <section> <title>Variables and literals</title> <p>Variables take the form <c><![CDATA['$<number>']]></c> where @@ -396,10 +435,8 @@ <c><![CDATA[MatchCondition]]></c> parts, only variables bound previously may be used. As a special case, in the <c><![CDATA[MatchCondition/MatchBody]]></c> parts, the variable <c><![CDATA['$_']]></c> - expands to the whole expression which matched the - <c><![CDATA[MatchHead]]></c> (i.e., the whole parameter list to the possibly - traced function or the whole matching object in the ets table) - and the variable <c><![CDATA['$$']]></c> expands to a list + expands to the whole <seealso marker="#match_target">match target</seealso> + term and the variable <c><![CDATA['$$']]></c> expands to a list of the values of all bound variables in order (i.e. <c><![CDATA[['$1','$2', ...]]]></c>). </p> @@ -480,8 +517,8 @@ <p>For each tuple in the <c><![CDATA[MatchExpression]]></c> list and while no match has succeeded:</p> <list type="bulleted"> - <item>Match the <c><![CDATA[MatchHead]]></c> part against the arguments to the - function, + <item>Match the <c><![CDATA[MatchHead]]></c> part against the + match target term, binding the <c><![CDATA['$<number>']]></c> variables (much like in <c><![CDATA[ets:match/2]]></c>). If the <c><![CDATA[MatchHead]]></c> cannot match the arguments, the match fails. @@ -522,13 +559,10 @@ term. The <c><![CDATA[ActionTerm]]></c>'s are executed as in an imperative language, i.e. for their side effects. Functions with side effects are also allowed when tracing.</p> - <p>In ETS the match head is a <c><![CDATA[tuple()]]></c> (or a single match - variable) while it is a list (or a single match variable) when - tracing.</p> </section> <section> - <title>ETS Examples</title> + <title>Tracing Examples</title> <p>Match an argument list of three where the first and third arguments are equal:</p> <code type="none"><![CDATA[ @@ -585,42 +619,6 @@ parameter list with a single variable is a special case. In all other cases the <c><![CDATA[MatchHead]]></c> has to be a <em>proper</em> list. </p> - <p>Match all objects in an ets table where the first element is - the atom 'strider' and the tuple arity is 3 and return the whole - object.</p> - <code type="none"><![CDATA[ -[{{strider,'_','_'}, - [], - ['$_']}] - ]]></code> - <p>Match all objects in an ets table with arity > 1 and the first - element is 'gandalf', return element 2.</p> - <code type="none"><![CDATA[ -[{'$1', - [{'==', gandalf, {element, 1, '$1'}},{'>=',{size, '$1'},2}], - [{element,2,'$1'}]}] - ]]></code> - <p>In the above example, if the first element had been the key, - it's much more efficient to match that key in the <c><![CDATA[MatchHead]]></c> - part than in the <c><![CDATA[MatchConditions]]></c> part. The search space of - the tables is restricted with regards to the <c><![CDATA[MatchHead]]></c> so - that only objects with the matching key are searched. - </p> - <p>Match tuples of 3 elements where the second element is either - 'merry' or 'pippin', return the whole objects.</p> - <code type="none"><![CDATA[ -[{{'_',merry,'_'}, - [], - ['$_']}, - {{'_',pippin,'_'}, - [], - ['$_']}] - ]]></code> - <p>The function <c><![CDATA[ets:test_ms/2]]></c> can be useful for testing - complicated ets matches.</p> - </section> - <section> - <title>Tracing Examples</title> <p>Only generate trace message if trace control word is set to 1:</p> <code type="none"><![CDATA[ [{'_', @@ -658,5 +656,42 @@ {'_',[],[]}] ]]></code> </section> + + <section> + <title>ETS Examples</title> + <p>Match all objects in an ets table where the first element is + the atom 'strider' and the tuple arity is 3 and return the whole + object.</p> + <code type="none"><![CDATA[ +[{{strider,'_','_'}, + [], + ['$_']}] + ]]></code> + <p>Match all objects in an ets table with arity > 1 and the first + element is 'gandalf', return element 2.</p> + <code type="none"><![CDATA[ +[{'$1', + [{'==', gandalf, {element, 1, '$1'}},{'>=',{size, '$1'},2}], + [{element,2,'$1'}]}] + ]]></code> + <p>In the above example, if the first element had been the key, + it's much more efficient to match that key in the <c><![CDATA[MatchHead]]></c> + part than in the <c><![CDATA[MatchConditions]]></c> part. The search space of + the tables is restricted with regards to the <c><![CDATA[MatchHead]]></c> so + that only objects with the matching key are searched. + </p> + <p>Match tuples of 3 elements where the second element is either + 'merry' or 'pippin', return the whole objects.</p> + <code type="none"><![CDATA[ +[{{'_',merry,'_'}, + [], + ['$_']}, + {{'_',pippin,'_'}, + [], + ['$_']}] + ]]></code> + <p>The function <c><![CDATA[ets:test_ms/2]]></c> can be useful for testing + complicated ets matches.</p> + </section> </chapter> diff --git a/erts/doc/src/notes.xml b/erts/doc/src/notes.xml index 7d39461f10..7501ccd9ce 100644 --- a/erts/doc/src/notes.xml +++ b/erts/doc/src/notes.xml @@ -32,631 +32,6 @@ <p>This document describes the changes made to the ERTS application.</p> -<section><title>Erts 8.0</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p>The handling of <c>on_load</c> functions has been - improved. The major improvement is that if a code upgrade - fails because the <c>on_load</c> function fails, the - previous version of the module will now be retained.</p> - <p> - Own Id: OTP-12593</p> - </item> - <item> - <p><c>is_builtin(erlang, apply, 3)</c> will now return - <c>true</c>.</p> - <p> - Own Id: OTP-13034</p> - </item> - <item> - <p> - Fix <c>enif_get_list_length</c> to return false if list - is improper or have length larger than <c>UINT_MAX</c> - (did return true and an incorrect length value).</p> - <p> - Own Id: OTP-13288 Aux Id: PR913 </p> - </item> - <item> - <p> - Cleanup hipe signal handling code for x86 and make it - more portable.</p> - <p> - Own Id: OTP-13341 Aux Id: PR951 </p> - </item> - <item> - <p> - Use fsync instead of fdatasync on Mac OSX.</p> - <p> - Own Id: OTP-13411</p> - </item> - <item> - <p> - Make sure to create a crash dump when running out of - memory. This was accidentally removed in the erts-7.3 - release.</p> - <p> - Own Id: OTP-13419</p> - </item> - <item> - <p> - A bug has been fixed where if erlang was started +B on a - unix platform it would be killed by a SIGUSR2 signal when - creating a crash dump.</p> - <p> - Own Id: OTP-13425</p> - </item> - <item> - <p> - Fix race between <c>process_flag(trap_exit,true)</c> and - a received exit signal.</p> - <p> - A process could terminate due to exit signal even though - <c>process_flag(trap_exit,true)</c> had returned. A very - specific timing between call to <c>process_flag/2</c> and - exit signal from another scheduler was required for this - to happen.</p> - <p> - Own Id: OTP-13452</p> - </item> - <item> - <p>Don't search for non-existing Map keys twice</p> - <p>For <c>maps:get/2,3</c> and <c>maps:find/2</c>, - searching for an immediate key, e.g. an atom, in a small - map, the search was performed twice if the key did not - exist.</p> - <p> - Own Id: OTP-13459</p> - </item> - <item> - <p> - When a abnormally large distribution message is about to - be sent, the VM has been changed to create a crash dump - instead of a core dump.</p> - <p> - Own Id: OTP-13474</p> - </item> - <item> - <p> - Fix <c>erlang:process_info/2</c> type specification</p> - <p> - Own Id: OTP-13485 Aux Id: ERL-123 </p> - </item> - <item> - <p> - Fix bug in <c>open_port/2</c> with option <c>{args, - List}</c>. A vm crash could be caused by an improper - <c>List</c>.</p> - <p> - Own Id: OTP-13489 Aux Id: ERL-127 </p> - </item> - <item> - <p> - Don't crash on terminating processes with - <c>erlang:system_profile/1,2</c></p> - <p> - Own Id: OTP-13494 Aux Id: ERL-126 </p> - </item> - <item> - <p> - Fixed bugs where the reduction counter was not handled - correct.</p> - <p> - Own Id: OTP-13512</p> - </item> - <item> - <p> - Fixed typo in description of the <c>EPMD_DUMP_REQ</c> - response.</p> - <p> - Own Id: OTP-13517</p> - </item> - <item> - <p> - Fixed a bug where a process flagged as sensitive would - sometimes record its save_calls when it shouldn't.</p> - <p> - Own Id: OTP-13540</p> - </item> - <item> - <p> - Update configure scripts to not use hardcoded path for - /bin/pwd and /bin/rm.</p> - <p> - Own Id: OTP-13562</p> - </item> - </list> - </section> - - - <section><title>Improvements and New Features</title> - <list> - <item> - <p> - The tracing support has been extended to allow a <seealso - marker="erl_tracer">tracer module</seealso> to be the - trace event handler instead of a process or port. The - <seealso marker="erl_tracer">tracer module</seealso> - makes it possible for trace tools to filter or manipulate - trace event data without the trace event first haing to - be copied from the traced process or port.</p> - <p> - With the introduction of this feature, - <c>erlang:trace(all|existing, _, _)</c> now also returns - the tracer process as part of the number of processes on - which tracing is enabled. The is incompatible with the - previous releases.</p> - <p> - *** POTENTIAL INCOMPATIBILITY ***</p> - <p> - Own Id: OTP-10267</p> - </item> - <item> - <p> - Introduce LTTng tracing of Erlang Runtime System</p> - <p> - For LTTng to be enabled OTP needs to be built with - configure option <c>--with-dynamic-trace=lttng</c>.</p> - <p> - This feature introduces tracepoints for schedulers, - drivers, memory carriers, memory and async thread pool.</p> - <p> For a list of all tracepoints, see <seealso - marker="runtime_tools:LTTng">Runtime Tools User's - Guide</seealso> .</p> - <p> - Own Id: OTP-10282 Aux Id: kunagi-14 [14] </p> - </item> - <item> - <p> - Add microstate accounting</p> - <p> - Microstate accounting is a way to track which state the - different threads within ERTS are in. The main usage area - is to pin point performance bottlenecks by checking which - states the threads are in and then from there figuring - out why and where to optimize.</p> - <p> - Since checking whether microstate accounting is on or off - is relatively expensive only a few of the states are - enabled by default and more states can be enabled through - configure.</p> - <p> - There is a convinence module called msacc that has been - added to runtime_tools that can assist in gathering and - interpreting the data from Microstate accounting.</p> - <p> - For more information see <seealso - marker="erts:erlang#statistics_microstate_accounting">erlang:statistics(microstate_accounting, - _)</seealso> and the <seealso - marker="runtime_tools:msacc">msacc</seealso> module in - runtime_tools.</p> - <p> - Own Id: OTP-12345</p> - </item> - <item> - <p> - The port of Erlang/OTP to the realtime operating system - OSE has been removed.</p> - <p> - Own Id: OTP-12573</p> - </item> - <item> - <p> - Sharing preserved copy for messages and exit signals</p> - <p> - Enable sharing preserved copy with configure option - <c>--enable-sharing-preserving</c>. This will preserve - sharing, within the process, when communication with - other processes in the Erlang node. There is a trade-off, - the copy is more costly but this cost can be reclaimed if - there is a lot of sharing in the message. With this - feature enabled literals will not be copied in a send - except during a purge phase of the module where the - literals are located.</p> - <p> - Own Id: OTP-12590 Aux Id: OTP-10251 </p> - </item> - <item> - <p> - Halfword BEAM has been removed.</p> - <p> - Own Id: OTP-12883</p> - </item> - <item> - <p> - Added <seealso - marker="kernel:os#perf_counter/1">os:perf_counter/1</seealso>.</p> - <p> - The perf_counter is a very very cheap and high resolution - timer that can be used to timestamp system events. It - does not have monoticity guarantees, but should on most - OS's expose a monotonous time.</p> - <p> - Own Id: OTP-12908</p> - </item> - <item> - <p> - Support for a fragmented young heap generation. That is, - the young heap generation can consist of multiple non - continuous memory areas. The main reason for this change - is to avoid extra copying of messages that could not be - allocated directly on the receivers heap.</p> - <p> - Own Id: OTP-13047</p> - </item> - <item> - <p> - Erlang linked-in driver can now force the call to - open_port to block until a call to erl_drv_init_ack is - made inside the driver. This is useful when you want to - do some asynchronous initialization, for example getting - configuration from a pipe, and you want the initial - open_port call to fail if the configuration is incomplete - or wrong. See the erl_driver documentation for more - details on the API.</p> - <p> - Own Id: OTP-13086</p> - </item> - <item> - <p> - Erlang linked-in drivers can now set their own pid's as - seen in <c>erlang:port_info/1</c> by using the - <c>erl_drv_set_pid</c> function. For more details see the - erl_driver documentation.</p> - <p> - Own Id: OTP-13087</p> - </item> - <item> - <p> - The functionality behind <c>erlang:open_port/2</c> when - called with spawn or spawn_executable has been redone so - that the forking of the new program is done in a separate - process called erl_child_setup. This allows for a much - more robust implementation that uses less memory and does - not block the entire emulator if the program to be - started is on an un-accessible NFS. Benchmarks have shown - this approach to be about 3-5 times as fast as the old - approach where the fork/vfork was done by erts. This is a - pure stability and performance fix, however some error - messages may have changed, which is why it is marked as a - backwards incompatible change.</p> - <p> - *** POTENTIAL INCOMPATIBILITY ***</p> - <p> - Own Id: OTP-13088</p> - </item> - <item> - <p>Improved yielding strategy in the implementation of - the following native functions:</p> <list> - <item><c>erlang:binary_to_list/1</c></item> - <item><c>erlang:binary_to_list/3</c></item> - <item><c>erlang:bitstring_to_list/1</c></item> - <item><c>erlang:list_to_binary/1</c></item> - <item><c>erlang:iolist_to_binary/1</c></item> - <item><c>erlang:list_to_bitstring/1</c></item> - <item><c>binary:list_to_bin/1</c></item> </list> <p>This - in order to improve performance of these functions.</p> - <p> - Own Id: OTP-13096</p> - </item> - <item> - <p> - All garbage collections of processes now bump reductions. - Also the amount of reductions bumped when garbage - collecting has been adjusted. It now better corresponds - to the amount of work performed. This in order to improve - the real time characteristics of the system.</p> - <p> - Own Id: OTP-13097</p> - </item> - <item> - <p>New functions that can load multiple functions at once - have been added to the '<c>code</c>' module. The - functions are <c>code:atomic_load/1</c>, - <c>code:prepare_loading/1</c>, - <c>code:finish_loading/1</c>, and - <c>code:ensure_modules_loaded/1</c>.</p> - <p> - Own Id: OTP-13111</p> - </item> - <item> - <p>The function <c>erl_prim_loader:start/3</c> has been - removed. Its documentation has also been removed.</p> - <p>The undocumented and unsupported function - <c>erl_prim_loader:get_files/2</c> has been removed.</p> - <p> - Own Id: OTP-13112</p> - </item> - <item> - <p> - Low level BIF <c>erlang:purge_module/1</c> is made more - robust against incorrect use. Lingering processes that - still refer the old code are now killed before the module - is purged to prevent fatal VM behavior.</p> - <p> - Own Id: OTP-13122</p> - </item> - <item> - <p> - Improved dirty scheduler implementation. For more - information see the <seealso - marker="erl_nif#dirty_nifs">NIF documentation</seealso>.</p> - <p> - Note that support for determining whether dirty NIF - support exist or not at compile time using the C - preprocessor macro <c>ERL_NIF_DIRTY_SCHEDULER_SUPPORT</c> - has been removed.</p> - <p> - Own Id: OTP-13123</p> - </item> - <item> - <p> - Various optimizations done to process dictionary access.</p> - <p> - Own Id: OTP-13167</p> - </item> - <item> - <p> - Added max_heap_size process flag. See erlang:process_flag - for more details.</p> - <p> - Own Id: OTP-13174</p> - </item> - <item> - <p> - Allow dynamic drivers and NIF libraries to be built with - gcc option <c>-fvisibility=hidden</c> for faster loading - and more optimized code.</p> - <p> - Own Id: OTP-13227</p> - </item> - <item> - <p> - Add <c>erlang:process_info(Pid, - garbage_collection_info)</c> which returns extended - garbage_collection information. For more details see the - documentation.</p> - <p> - Own Id: OTP-13265</p> - </item> - <item> - <p> - The functions <c>erlang:list_to_integer/1</c> and - <c>string:to_integer/1</c> have been optimized for large - inputs.</p> - <p> - Own Id: OTP-13293</p> - </item> - <item> - <p> - Introduction of configurable management of data referred - to by the message queue of a process. Each process can be - configured individually.</p> - <p> - It is now possible to configure the message queue of a - process, so that all data referred by it will be kept - outside of the heap, and by this prevent this data from - being part of garbage collections.</p> - <p> - For more information see the documentation of <seealso - marker="erlang#process_flag_message_queue_data"><c>process_flag(message_queue_data, - MQD)</c></seealso>.</p> - <p> - Own Id: OTP-13366 Aux Id: OTP-13047 </p> - </item> - <item> - <p> - Processes now yield when scanning large message queues - and not finding a matching message. This in order to - improve real time characteristics.</p> - <p> - Own Id: OTP-13401</p> - </item> - <item> - <p> - Optimized an erts internal function that is used to - traverse erlang terms. The internal function was mainly - used by term_to_binary and comparison of terms. - Benchmarks have shown up to a 10% performance increase in - those functions after the optimization.</p> - <p> - Own Id: OTP-13440</p> - </item> - <item> - <p> - Add the following NIF API functions:</p> - <p> - <list> <item><seealso - marker="erl_nif#enif_cpu_time"><c>enif_cpu_time</c></seealso></item> - <item><seealso - marker="erl_nif#enif_now_time"><c>enif_now_time</c></seealso></item> - <item><seealso - marker="erl_nif#enif_make_unique_integer"><c>enif_make_unique_integer</c></seealso></item> - <item><seealso - marker="erl_nif#enif_is_process_alive"><c>enif_is_process_alive</c></seealso></item> - <item><seealso - marker="erl_nif#enif_is_port_alive"><c>enif_is_port_alive</c></seealso></item> - <item><seealso - marker="erl_nif#enif_term_to_binary"><c>enif_term_to_binary</c></seealso></item> - <item><seealso - marker="erl_nif#enif_binary_to_term"><c>enif_binary_to_term</c></seealso></item> - <item><seealso - marker="erl_nif#enif_port_command"><c>enif_port_command</c></seealso></item> - </list></p> - <p> - for details of what each function does, see the erl_nif - documentation.</p> - <p> - Own Id: OTP-13442</p> - </item> - <item> - <p> - Optimize <c>'++'</c> operator and <c>lists:append/2</c> - by using a single pass to build a new list while checking - for properness.</p> - <p> - Own Id: OTP-13487</p> - </item> - <item> - <p> - Handle terms (pids,ports and refs) from nodes with a - 'creation' value larger than 3. This is a preparation of - the distribution protocol to allow OTP 19 nodes to - correctly communicate with future nodes (20 or higher). - The 'creation' value differentiates different - incarnations of the same node (name).</p> - <p> - Own Id: OTP-13488</p> - </item> - <item> - <p> - Don't send unasked for systemd notifications in epmd</p> - <p> - Own Id: OTP-13493 Aux Id: PR-999 </p> - </item> - <item> - <p> - The enif_send API has been extended to allow NULL to be - used as the message environment. When used this way, a - message environent is implicitly created and the given - term is copied into that environment before sending. This - can be an optimization if many small messages are being - sent by the nif.</p> - <p> - Own Id: OTP-13495</p> - </item> - <item> - <p> - The tracing support has been extended to allow tracing on - ports. Ports can be traced on using the 'ports', 'send' - and 'receive' trace flags.</p> - <p> - The first argument of <seealso - marker="erts:erlang#trace/3">erlang:trace/3</seealso> has - been extended so that <c>'all'</c>, <c>'existing'</c> and - <c>'new'</c> now include both processes and ports. New - <c>Tracee</c> variants, <c>'all_processes'</c>, - <c>'all_ports'</c>, <c>'existing_processes'</c> etc have - been added to specify only processes or ports.</p> - <p> - *** POTENTIAL INCOMPATIBILITY ***</p> - <p> - Own Id: OTP-13496</p> - </item> - <item> - <p> - When the <c>'procs'</c> trace flag is enabled, a - <c>'spawned'</c> trace event is now also generated by a - newly created process. The previous event <c>'spawn'</c> - remains, but as it is generated by the process that did - the spawn, it is not guaranteed that it is ordered with - other trace events from the newly spawned process. So - when tracking the lifetime of a process this new event - should be used as the creation event.</p> - <p> - This new trace event is marked as an incompatabiliy - because tools that expect certain trace events when - enabling 'procs' will have to updated.</p> - <p> - *** POTENTIAL INCOMPATIBILITY ***</p> - <p> - Own Id: OTP-13497</p> - </item> - <item> - <p> - Add the <seealso - marker="erts:erlang#match_spec_test/3">erlang:match_spec_test/3</seealso> - function. The functions allows the testing of match - specifications for both tracing and ets tables. It can be - used to test that a match specification does the expected - filtering on specific data. It also returns more verbose - error reasons for incorrectly constructed match - specifications.</p> - <p> - Own Id: OTP-13501</p> - </item> - <item> - <p> - The erts internal tracing support has been changed to - have much less overhead and be more scalable.</p> - <p> - This rewrite does not break any backwards - incompatabilities, but it does change the ordering of - some trace messages when compared to previous releases. - It should be noted that this only applies to trace - messages sent to processes or ports, it does not apply to - the new tracer module. However in future releases they - may also be effected by this.</p> - <p> - Trace messages are only guaranteed to be ordered from one - traced process or port. In previous releases this was not - visible as a <c>'send'</c> trace message would always - arrive before the corresponding <c>'receive'</c> trace - message that is no longer always the case. This also - means that timestamped trace messages may seem to arrive - out of order as the timestamp is taken when the event is - triggered and not when it is put in the queue of the - tracer.</p> - <p> - Own Id: OTP-13503</p> - </item> - <item> - <p> - Add possibility to filter <c>send</c> and <c>receive</c> - trace with match specifications.</p> - <p> - Own Id: OTP-13507</p> - </item> - <item> - <p> - Add <c>maps:update_with/3,4</c> and <c>maps:take/2</c></p> - <p> - Own Id: OTP-13522 Aux Id: PR-1025 </p> - </item> - <item> - <p> - Introduce LTTng tracing via Erlang tracing.</p> - <p> - For LTTng to be enabled OTP needs to be built with - configure option <c>--with-dynamic-trace=lttng</c>.</p> - <p>The dynamic trace module <c>dyntrace</c> is now - capable to be used as a LTTng sink for Erlang tracing. - For a list of all tracepoints, see <seealso - marker="runtime_tools:LTTng">Runtime Tools User's - Guide</seealso> .</p> - <p>This feature also introduces an incompatible change in - trace tags. The trace tags <c>gc_start</c> and - <c>gc_end</c> has been split into <c>gc_minor_start</c>, - <c>gc_minor_end</c> and <c>gc_major_start</c>, - <c>gc_major_end</c>.</p> - <p> - *** POTENTIAL INCOMPATIBILITY ***</p> - <p> - Own Id: OTP-13532</p> - </item> - <item> - <p> - Print heap pointers for garbing processes during - crashdump</p> - <p> - Own Id: OTP-13541 Aux Id: PR-1026 </p> - </item> - <item> - <p> - Changed and improved low level memory statistics returned - by <c>erlang:system_info/1</c>. The info for - <c>erts_mmap</c> has been moved from <c>mseg_alloc</c> to - its own section returned by <c>{allocator, - erts_mmap}</c>.</p> - <p> - Own Id: OTP-13560</p> - </item> - </list> - </section> - -</section> - <section><title>Erts 7.3.1</title> <section><title>Fixed Bugs and Malfunctions</title> |