libstdc++: Delete further Profile Mode leftovers
Commit 544be2beb1 in 2019 remove Profile Mode and associated docs.
Now also remove generated HTML files.
libstdc++-v3:
* doc/html/manual/profile_mode.html: Delete.
* doc/html/manual/profile_mode_api.html: Ditto.
* doc/html/manual/profile_mode_cost_model.html: Ditto.
* doc/html/manual/profile_mode_design.html: Ditto.
* doc/html/manual/profile_mode_devel.html: Ditto.
* doc/html/manual/profile_mode_impl.html: Ditto.
This commit is contained in:
Gerald Pfeifer
parent
9b1d30e83e
commit
60ef4b9cc9
6 changed files with 0 additions and 409 deletions
File diff suppressed because one or more lines are too long
|
|
@ -1,9 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Extensions for Custom Containers</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="C++, library, profile" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="profile_mode.html" title="Chapter 19. Profile Mode" /><link rel="prev" href="profile_mode_design.html" title="Design" /><link rel="next" href="profile_mode_cost_model.html" title="Empirical Cost Model" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Extensions for Custom Containers</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="profile_mode_design.html">Prev</a> </td><th width="60%" align="center">Chapter 19. Profile Mode</th><td width="20%" align="right"> <a accesskey="n" href="profile_mode_cost_model.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.profile_mode.api"></a>Extensions for Custom Containers</h2></div></div></div><p>
|
||||
Many large projects use their own data structures instead of the ones in the
|
||||
standard library. If these data structures are similar in functionality
|
||||
to the standard library, they can be instrumented with the same hooks
|
||||
that are used to instrument the standard library.
|
||||
The instrumentation API is exposed in file
|
||||
<code class="code">profiler.h</code> (look for "Instrumentation hooks").
|
||||
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="profile_mode_design.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="profile_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="profile_mode_cost_model.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Design </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Empirical Cost Model</td></tr></table></div></body></html>
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Empirical Cost Model</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="C++, library, profile" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="profile_mode.html" title="Chapter 19. Profile Mode" /><link rel="prev" href="profile_mode_api.html" title="Extensions for Custom Containers" /><link rel="next" href="profile_mode_impl.html" title="Implementation Issues" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Empirical Cost Model</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="profile_mode_api.html">Prev</a> </td><th width="60%" align="center">Chapter 19. Profile Mode</th><td width="20%" align="right"> <a accesskey="n" href="profile_mode_impl.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.profile_mode.cost_model"></a>Empirical Cost Model</h2></div></div></div><p>
|
||||
Currently, the cost model uses formulas with predefined relative weights
|
||||
for alternative containers or container implementations. For instance,
|
||||
iterating through a vector is X times faster than iterating through a list.
|
||||
</p><p>
|
||||
(Under development.)
|
||||
We are working on customizing this to a particular machine by providing
|
||||
an automated way to compute the actual relative weights for operations
|
||||
on the given machine.
|
||||
</p><p>
|
||||
(Under development.)
|
||||
We plan to provide a performance parameter database format that can be
|
||||
filled in either by hand or by an automated training mechanism.
|
||||
The analysis module will then use this database instead of the built in.
|
||||
generic parameters.
|
||||
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="profile_mode_api.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="profile_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="profile_mode_impl.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Extensions for Custom Containers </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Implementation Issues</td></tr></table></div></body></html>
|
||||
|
|
@ -1,121 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="C++, library, profile" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="profile_mode.html" title="Chapter 19. Profile Mode" /><link rel="prev" href="profile_mode.html" title="Chapter 19. Profile Mode" /><link rel="next" href="profile_mode_api.html" title="Extensions for Custom Containers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="profile_mode.html">Prev</a> </td><th width="60%" align="center">Chapter 19. Profile Mode</th><td width="20%" align="right"> <a accesskey="n" href="profile_mode_api.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.profile_mode.design"></a>Design</h2></div></div></div><p>
|
||||
</p><div class="table"><a id="table.profile_code_loc"></a><p class="title"><strong>Table 19.1. Profile Code Location</strong></p><div class="table-contents"><table class="table" summary="Profile Code Location" border="1"><colgroup><col align="left" class="c1" /><col align="left" class="c2" /></colgroup><thead><tr><th align="left">Code Location</th><th align="left">Use</th></tr></thead><tbody><tr><td align="left"><code class="code">libstdc++-v3/include/std/*</code></td><td align="left">Preprocessor code to redirect to profile extension headers.</td></tr><tr><td align="left"><code class="code">libstdc++-v3/include/profile/*</code></td><td align="left">Profile extension public headers (map, vector, ...).</td></tr><tr><td align="left"><code class="code">libstdc++-v3/include/profile/impl/*</code></td><td align="left">Profile extension internals. Implementation files are
|
||||
only included from <code class="code">impl/profiler.h</code>, which is the only
|
||||
file included from the public headers.</td></tr></tbody></table></div></div><br class="table-break" /><p>
|
||||
</p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.design.wrapper"></a>Wrapper Model</h3></div></div></div><p>
|
||||
In order to get our instrumented library version included instead of the
|
||||
release one,
|
||||
we use the same wrapper model as the debug mode.
|
||||
We subclass entities from the release version. Wherever
|
||||
<code class="code">_GLIBCXX_PROFILE</code> is defined, the release namespace is
|
||||
<code class="code">std::__norm</code>, whereas the profile namespace is
|
||||
<code class="code">std::__profile</code>. Using plain <code class="code">std</code> translates
|
||||
into <code class="code">std::__profile</code>.
|
||||
</p><p>
|
||||
Whenever possible, we try to wrap at the public interface level, e.g.,
|
||||
in <code class="code">unordered_set</code> rather than in <code class="code">hashtable</code>,
|
||||
in order not to depend on implementation.
|
||||
</p><p>
|
||||
Mixing object files built with and without the profile mode must
|
||||
not affect the program execution. However, there are no guarantees to
|
||||
the accuracy of diagnostics when using even a single object not built with
|
||||
<code class="code">-D_GLIBCXX_PROFILE</code>.
|
||||
Currently, mixing the profile mode with debug and parallel extensions is
|
||||
not allowed. Mixing them at compile time will result in preprocessor errors.
|
||||
Mixing them at link time is undefined.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.design.instrumentation"></a>Instrumentation</h3></div></div></div><p>
|
||||
Instead of instrumenting every public entry and exit point,
|
||||
we chose to add instrumentation on demand, as needed
|
||||
by individual diagnostics.
|
||||
The main reason is that some diagnostics require us to extract bits of
|
||||
internal state that are particular only to that diagnostic.
|
||||
We plan to formalize this later, after we learn more about the requirements
|
||||
of several diagnostics.
|
||||
</p><p>
|
||||
All the instrumentation points can be switched on and off using
|
||||
<code class="code">-D[_NO]_GLIBCXX_PROFILE_<diagnostic></code> options.
|
||||
With all the instrumentation calls off, there should be negligible
|
||||
overhead over the release version. This property is needed to support
|
||||
diagnostics based on timing of internal operations. For such diagnostics,
|
||||
we anticipate turning most of the instrumentation off in order to prevent
|
||||
profiling overhead from polluting time measurements, and thus diagnostics.
|
||||
</p><p>
|
||||
All the instrumentation on/off compile time switches live in
|
||||
<code class="code">include/profile/profiler.h</code>.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.design.rtlib"></a>Run Time Behavior</h3></div></div></div><p>
|
||||
For practical reasons, the instrumentation library processes the trace
|
||||
partially
|
||||
rather than dumping it to disk in raw form. Each event is processed when
|
||||
it occurs. It is usually attached a cost and it is aggregated into
|
||||
the database of a specific diagnostic class. The cost model
|
||||
is based largely on the standard performance guarantees, but in some
|
||||
cases we use knowledge about GCC's standard library implementation.
|
||||
</p><p>
|
||||
Information is indexed by (1) call stack and (2) instance id or address
|
||||
to be able to understand and summarize precise creation-use-destruction
|
||||
dynamic chains. Although the analysis is sensitive to dynamic instances,
|
||||
the reports are only sensitive to call context. Whenever a dynamic instance
|
||||
is destroyed, we accumulate its effect to the corresponding entry for the
|
||||
call stack of its constructor location.
|
||||
</p><p>
|
||||
For details, see
|
||||
<a class="link" href="https://ieeexplore.ieee.org/document/4907670/" target="_top">paper presented at
|
||||
CGO 2009</a>.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.design.analysis"></a>Analysis and Diagnostics</h3></div></div></div><p>
|
||||
Final analysis takes place offline, and it is based entirely on the
|
||||
generated trace and debugging info in the application binary.
|
||||
See section Diagnostics for a list of analysis types that we plan to support.
|
||||
</p><p>
|
||||
The input to the analysis is a table indexed by profile type and call stack.
|
||||
The data type for each entry depends on the profile type.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.design.cost-model"></a>Cost Model</h3></div></div></div><p>
|
||||
While it is likely that cost models become complex as we get into
|
||||
more sophisticated analysis, we will try to follow a simple set of rules
|
||||
at the beginning.
|
||||
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><span class="emphasis"><em>Relative benefit estimation:</em></span>
|
||||
The idea is to estimate or measure the cost of all operations
|
||||
in the original scenario versus the scenario we advise to switch to.
|
||||
For instance, when advising to change a vector to a list, an occurrence
|
||||
of the <code class="code">insert</code> method will generally count as a benefit.
|
||||
Its magnitude depends on (1) the number of elements that get shifted
|
||||
and (2) whether it triggers a reallocation.
|
||||
</p></li><li class="listitem"><p><span class="emphasis"><em>Synthetic measurements:</em></span>
|
||||
We will measure the relative difference between similar operations on
|
||||
different containers. We plan to write a battery of small tests that
|
||||
compare the times of the executions of similar methods on different
|
||||
containers. The idea is to run these tests on the target machine.
|
||||
If this training phase is very quick, we may decide to perform it at
|
||||
library initialization time. The results can be cached on disk and reused
|
||||
across runs.
|
||||
</p></li><li class="listitem"><p><span class="emphasis"><em>Timers:</em></span>
|
||||
We plan to use timers for operations of larger granularity, such as sort.
|
||||
For instance, we can switch between different sort methods on the fly
|
||||
and report the one that performs best for each call context.
|
||||
</p></li><li class="listitem"><p><span class="emphasis"><em>Show stoppers:</em></span>
|
||||
We may decide that the presence of an operation nullifies the advice.
|
||||
For instance, when considering switching from <code class="code">set</code> to
|
||||
<code class="code">unordered_set</code>, if we detect use of operator <code class="code">++</code>,
|
||||
we will simply not issue the advice, since this could signal that the use
|
||||
care require a sorted container.</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.design.reports"></a>Reports</h3></div></div></div><p>
|
||||
There are two types of reports. First, if we recognize a pattern for which
|
||||
we have a substitute that is likely to give better performance, we print
|
||||
the advice and estimated performance gain. The advice is usually associated
|
||||
to a code position and possibly a call stack.
|
||||
</p><p>
|
||||
Second, we report performance characteristics for which we do not have
|
||||
a clear solution for improvement. For instance, we can point to the user
|
||||
the top 10 <code class="code">multimap</code> locations
|
||||
which have the worst data locality in actual traversals.
|
||||
Although this does not offer a solution,
|
||||
it helps the user focus on the key problems and ignore the uninteresting ones.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.design.testing"></a>Testing</h3></div></div></div><p>
|
||||
First, we want to make sure we preserve the behavior of the release mode.
|
||||
You can just type <code class="code">"make check-profile"</code>, which
|
||||
builds and runs the whole test suite in profile mode.
|
||||
</p><p>
|
||||
Second, we want to test the correctness of each diagnostic.
|
||||
We created a <code class="code">profile</code> directory in the test suite.
|
||||
Each diagnostic must come with at least two tests, one for false positives
|
||||
and one for false negatives.
|
||||
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="profile_mode.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="profile_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="profile_mode_api.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 19. Profile Mode </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Extensions for Custom Containers</td></tr></table></div></body></html>
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Developer Information</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="C++, library, profile" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="profile_mode.html" title="Chapter 19. Profile Mode" /><link rel="prev" href="profile_mode_impl.html" title="Implementation Issues" /><link rel="next" href="profile_mode_diagnostics.html" title="Diagnostics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Developer Information</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="profile_mode_impl.html">Prev</a> </td><th width="60%" align="center">Chapter 19. Profile Mode</th><td width="20%" align="right"> <a accesskey="n" href="profile_mode_diagnostics.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.profile_mode.developer"></a>Developer Information</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.developer.bigpic"></a>Big Picture</h3></div></div></div><p>The profile mode headers are included with
|
||||
<code class="code">-D_GLIBCXX_PROFILE</code> through preprocessor directives in
|
||||
<code class="code">include/std/*</code>.
|
||||
</p><p>Instrumented implementations are provided in
|
||||
<code class="code">include/profile/*</code>. All instrumentation hooks are macros
|
||||
defined in <code class="code">include/profile/profiler.h</code>.
|
||||
</p><p>All the implementation of the instrumentation hooks is in
|
||||
<code class="code">include/profile/impl/*</code>. Although all the code gets included,
|
||||
thus is publicly visible, only a small number of functions are called from
|
||||
outside this directory. All calls to hook implementations must be
|
||||
done through macros defined in <code class="code">profiler.h</code>. The macro
|
||||
must ensure (1) that the call is guarded against reentrance and
|
||||
(2) that the call can be turned off at compile time using a
|
||||
<code class="code">-D_GLIBCXX_PROFILE_...</code> compiler option.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.developer.howto"></a>How To Add A Diagnostic</h3></div></div></div><p>Let's say the diagnostic name is "magic".
|
||||
</p><p>If you need to instrument a header not already under
|
||||
<code class="code">include/profile/*</code>, first edit the corresponding header
|
||||
under <code class="code">include/std/</code> and add a preprocessor directive such
|
||||
as the one in <code class="code">include/std/vector</code>:
|
||||
</p><pre class="programlisting">
|
||||
#ifdef _GLIBCXX_PROFILE
|
||||
# include <profile/vector>
|
||||
#endif
|
||||
</pre><p>
|
||||
</p><p>If the file you need to instrument is not yet under
|
||||
<code class="code">include/profile/</code>, make a copy of the one in
|
||||
<code class="code">include/debug</code>, or the main implementation.
|
||||
You'll need to include the main implementation and inherit the classes
|
||||
you want to instrument. Then define the methods you want to instrument,
|
||||
define the instrumentation hooks and add calls to them.
|
||||
Look at <code class="code">include/profile/vector</code> for an example.
|
||||
</p><p>Add macros for the instrumentation hooks in
|
||||
<code class="code">include/profile/impl/profiler.h</code>.
|
||||
Hook names must start with <code class="code">__profcxx_</code>.
|
||||
Make sure they transform
|
||||
in no code with <code class="code">-D_NO_GLIBCXX_PROFILE_MAGIC</code>.
|
||||
Make sure all calls to any method in namespace <code class="code">__gnu_profile</code>
|
||||
is protected against reentrance using macro
|
||||
<code class="code">_GLIBCXX_PROFILE_REENTRANCE_GUARD</code>.
|
||||
All names of methods in namespace <code class="code">__gnu_profile</code> called from
|
||||
<code class="code">profiler.h</code> must start with <code class="code">__trace_magic_</code>.
|
||||
</p><p>Add the implementation of the diagnostic.
|
||||
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
|
||||
Create new file <code class="code">include/profile/impl/profiler_magic.h</code>.
|
||||
</p></li><li class="listitem"><p>
|
||||
Define class <code class="code">__magic_info: public __object_info_base</code>.
|
||||
This is the representation of a line in the object table.
|
||||
The <code class="code">__merge</code> method is used to aggregate information
|
||||
across all dynamic instances created at the same call context.
|
||||
The <code class="code">__magnitude</code> must return the estimation of the benefit
|
||||
as a number of small operations, e.g., number of words copied.
|
||||
The <code class="code">__write</code> method is used to produce the raw trace.
|
||||
The <code class="code">__advice</code> method is used to produce the advice string.
|
||||
</p></li><li class="listitem"><p>
|
||||
Define class <code class="code">__magic_stack_info: public __magic_info</code>.
|
||||
This defines the content of a line in the stack table.
|
||||
</p></li><li class="listitem"><p>
|
||||
Define class <code class="code">__trace_magic: public __trace_base<__magic_info,
|
||||
__magic_stack_info></code>.
|
||||
It defines the content of the trace associated with this diagnostic.
|
||||
</p></li></ul></div><p>
|
||||
</p><p>Add initialization and reporting calls in
|
||||
<code class="code">include/profile/impl/profiler_trace.h</code>. Use
|
||||
<code class="code">__trace_vector_to_list</code> as an example.
|
||||
</p><p>Add documentation in file <code class="code">doc/xml/manual/profile_mode.xml</code>.
|
||||
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="profile_mode_impl.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="profile_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="profile_mode_diagnostics.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Implementation Issues </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Diagnostics</td></tr></table></div></body></html>
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Implementation Issues</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="C++, library, profile" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="profile_mode.html" title="Chapter 19. Profile Mode" /><link rel="prev" href="profile_mode_cost_model.html" title="Empirical Cost Model" /><link rel="next" href="profile_mode_devel.html" title="Developer Information" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Implementation Issues</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="profile_mode_cost_model.html">Prev</a> </td><th width="60%" align="center">Chapter 19. Profile Mode</th><td width="20%" align="right"> <a accesskey="n" href="profile_mode_devel.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.profile_mode.implementation"></a>Implementation Issues</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.stack"></a>Stack Traces</h3></div></div></div><p>
|
||||
Accurate stack traces are needed during profiling since we group events by
|
||||
call context and dynamic instance. Without accurate traces, diagnostics
|
||||
may be hard to interpret. For instance, when giving advice to the user
|
||||
it is imperative to reference application code, not library code.
|
||||
</p><p>
|
||||
Currently we are using the libc <code class="code">backtrace</code> routine to get
|
||||
stack traces.
|
||||
<code class="code">_GLIBCXX_PROFILE_STACK_DEPTH</code> can be set
|
||||
to 0 if you are willing to give up call context information, or to a small
|
||||
positive value to reduce run time overhead.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.symbols"></a>Symbolization of Instruction Addresses</h3></div></div></div><p>
|
||||
The profiling and analysis phases use only instruction addresses.
|
||||
An external utility such as addr2line is needed to postprocess the result.
|
||||
We do not plan to add symbolization support in the profile extension.
|
||||
This would require access to symbol tables, debug information tables,
|
||||
external programs or libraries and other system dependent information.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.concurrency"></a>Concurrency</h3></div></div></div><p>
|
||||
Our current model is simplistic, but precise.
|
||||
We cannot afford to approximate because some of our diagnostics require
|
||||
precise matching of operations to container instance and call context.
|
||||
During profiling, we keep a single information table per diagnostic.
|
||||
There is a single lock per information table.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.stdlib-in-proflib"></a>Using the Standard Library in the Instrumentation Implementation</h3></div></div></div><p>
|
||||
As much as we would like to avoid uses of libstdc++ within our
|
||||
instrumentation library, containers such as unordered_map are very
|
||||
appealing. We plan to use them as long as they are named properly
|
||||
to avoid ambiguity.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.malloc-hooks"></a>Malloc Hooks</h3></div></div></div><p>
|
||||
User applications/libraries can provide malloc hooks.
|
||||
When the implementation of the malloc hooks uses stdlibc++, there can
|
||||
be an infinite cycle between the profile mode instrumentation and the
|
||||
malloc hook code.
|
||||
</p><p>
|
||||
We protect against reentrance to the profile mode instrumentation code,
|
||||
which should avoid this problem in most cases.
|
||||
The protection mechanism is thread safe and exception safe.
|
||||
This mechanism does not prevent reentrance to the malloc hook itself,
|
||||
which could still result in deadlock, if, for instance, the malloc hook
|
||||
uses non-recursive locks.
|
||||
XXX: A definitive solution to this problem would be for the profile extension
|
||||
to use a custom allocator internally, and perhaps not to use libstdc++.
|
||||
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.profile_mode.implementation.construction-destruction"></a>Construction and Destruction of Global Objects</h3></div></div></div><p>
|
||||
The profiling library state is initialized at the first call to a profiling
|
||||
method. This allows us to record the construction of all global objects.
|
||||
However, we cannot do the same at destruction time. The trace is written
|
||||
by a function registered by <code class="code">atexit</code>, thus invoked by
|
||||
<code class="code">exit</code>.
|
||||
</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="profile_mode_cost_model.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="profile_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="profile_mode_devel.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Empirical Cost Model </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Developer Information</td></tr></table></div></body></html>
|
||||
Loading…
Add table
Reference in a new issue