From 6969ae73662f7c507977a9560a858a5964c791c4 Mon Sep 17 00:00:00 2001
From: Patrik Nyblom
Returns an atom describing the dynamic trace framework
+ compiled into the virtual machine. It can currently be either
+
Returns a
This option will be removed in a future release.
diff --git a/lib/runtime_tools/doc/src/Makefile b/lib/runtime_tools/doc/src/Makefile
index dbbae81cfe..f1dd788f80 100644
--- a/lib/runtime_tools/doc/src/Makefile
+++ b/lib/runtime_tools/doc/src/Makefile
@@ -40,7 +40,7 @@ RELSYSDIR = $(RELEASE_PATH)/lib/$(APPLICATION)-$(VSN)
# Target Specs
# ----------------------------------------------------
XML_APPLICATION_FILES = ref_man.xml
-XML_REF3_FILES = dbg.xml erts_alloc_config.xml
+XML_REF3_FILES = dbg.xml dyntrace.xml erts_alloc_config.xml
XML_REF6_FILES = runtime_tools_app.xml
XML_PART_FILES = part_notes.xml part_notes_history.xml
diff --git a/lib/runtime_tools/doc/src/dyntrace.xml b/lib/runtime_tools/doc/src/dyntrace.xml
new file mode 100644
index 0000000000..5fc5530f25
--- /dev/null
+++ b/lib/runtime_tools/doc/src/dyntrace.xml
@@ -0,0 +1,209 @@
+
+
+
+ This module implements interfaces to dynamic tracing, should such be compiled into the virtual machine. For a standard and/or commercial build, no dynamic tracing is available, in which case none of the functions in this module is usable or give any effect. Should dynamic tracing be enabled in the current build, either by configuring with Both building with dynamic trace probes and using them is experimental and unsupported by Erlang/OTP. It is included as an option for the developer to trace and debug performance issues in their systems. The original implementation is mostly done by Scott Lystiger Fritchie as an Open Source Contribution and it should be viewed as such even though the source for dynamic tracing as well as this module is included in the main distribution. However, the ability to use dynamic tracing of the virtual machine is a very valuable contribution which OTP has every intention to maintain as a tool for the developer. How to write This function uses the NIF library to determine if dynamic
+ tracing is available. Usually calling The function will throw an exception if the Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message only containing the user tag and zeroes/empty strings in all other fields. Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message containing the user tag and the integer or string parameter in the first integer/string field. Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message containing the user tag and the integer() or string() parameters as the first fields of respective type. integer() parameters should be put before any string() parameters. I.e. Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message containing the user tag and the integer() or string() parameters as the first fields of respective type. integer() parameters should be put before any string() parameters, as in Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message containing the user tag and the integer() or string() parameters as the first fields of respective type. integer() parameters should be put before any string() parameters, as in Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message containing the user tag and the integer() or string() parameters as the first fields of respective type. integer() parameters should be put before any string() parameters, as in There can be no more than four parameters of any type (integer() or string()), so the first parameter has to be an integer() and the last a string(). Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message containing the user tag and the integer() or string() parameters as the first fields of respective type. integer() parameters should be put before any string() parameters, as in There can be no more than four parameters of any type (integer() or string()), so the first two parameters has to be integer()'s and the last two string()'s. Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message containing the user tag and the integer() or string() parameters as the first fields of respective type. integer() parameters should be put before any string() parameters, as in There can be no more than four parameters of any type (integer() or string()), so the first three parameters has to be integer()'s and the last three string()'s. Calling this function will trigger the "user" trace probe user_trace_i4s4 in the dyntrace NIF module, sending a trace message containing all the integer()'s and string()'s provided, as well as any user tag set in the current process. This function returns the user tag set in the current
+ process. If no tag is set or dynamic tracing is not available,
+ it returns This function returns the user tag set in the current
+ process or, if no user tag is present, the last user tag sent
+ to the process together with a message (in the same way as
+ This function sets the user tag of the current process. The user tag is a binary(), but can be specified as any iodata(), which is automatically converted to a binary by this function. The user tag is provided to the user probes triggered by calls top The old user tag (if any) is returned, or This function controls if user tags are to be spread to other processes with the next message. Spreading of user tags work like spreading of sequential trace tokens, so that a received user tag will be active in the process until the next message arrives (if that message does not also contain the user tag. This functionality is used when a client process communicates with a file i/o-server to spread the user tag to the I/O-server and then down to the efile_drv driver. By using The The most use of this function would be if one for example uses the In this example, any user tag set in the calling process will be spread to the I/O-server when the io:format call is done. Restores the previous state of user tags and their spreading as it was before a call to Correctly handling user tags and their spreading might take some effort, as Erlang programs tend to send and receive messages so that sometimes the user tag gets lost due to various things, like double receives or communication with a port (ports do not handle user tags, in the same way as they do not handle regular sequential trace tokens).
+
+
+f() ->
+ {ok, F} = file:open("test.tst",[write]),
+ Saved = dyntrace:spread_tag(true),
+ io:format(F,"Hello world!",[]),
+ dyntrace:restore_tag(Saved),
+ file:close(F).
+
+
+f() ->
+ TagData=dyntrace:spread_tag(false),
+ spawn(fun() ->
+ dyntrace:restore_tag(TagData),
+ do_something()
+ end),
+ do_something_else(),
+ dyntrace:restore_tag(TagData).
+
+