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.
Currently we are using the libc backtrace routine to get
stack traces.
_GLIBCXX_PROFILE_STACK_DEPTH 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.
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.
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.
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.
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.
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++.
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 atexit, thus invoked by
exit.
@ 1.1.1.1.28.1 log @Sync with HEAD, resolve a couple of conflicts @ text @d2 1 a2 1
@ 1.1.1.2 log @import GCC 6.5.0. this is largely a maint release with no particularly features listed here: http://gcc.gnu.org/gcc-6/changes.html this fixes over 250 PRs in the GCC bugzilla: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.5 @ text @d2 1 a2 1
@ 1.1.1.1.8.1 log @file profile_mode_impl.html was added on branch tls-maxphys on 2014-08-19 23:54:46 +0000 @ text @d1 50 @ 1.1.1.1.8.2 log @Rebase to HEAD as of a few days ago. @ text @a0 50
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.
Currently we are using the libc backtrace routine to get
stack traces.
_GLIBCXX_PROFILE_STACK_DEPTH 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.
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.
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.
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.
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.
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++.
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 atexit, thus invoked by
exit.
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.
Currently we are using the libc backtrace routine to get
stack traces.
_GLIBCXX_PROFILE_STACK_DEPTH 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.
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.
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.
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.
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.
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++.
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 atexit, thus invoked by
exit.