Re: ping -- Re: merge branch profile-stdlib

[Silvius Rus <rus at google dot com>]

On Mon, Jun 8, 2009 at 2:38 PM, Jonathan Wakely<jwakely.gcc@gmail.com> wrote:
> 2009/6/8 Silvius Rus:
>>> - Uglified names.  I did this by placing all diagnostic implementation
>>> under namespace __cxxprof_impl.  (Is this sufficient?)
>
> Users are allowed to say
> #define turn_on 1
> #include <vector>
>
> It looks like this would cause an error if profiled.
>

Yes.  I had not considered the preprocessor, due to inertia from when
this was a run time library.  I need to change really all names then.
I'll prefix names with __glibcxx.

>
>>> - We are using vector and unordered_map in the implementation, with
>>> default allocators.  This can cause infinite cycles if say the
>>> application code uses libstdc++ containers to gather allocation
>>> statistics.
>
> That seems problematic to me - does it mean that users wanting to
> improve their use of standard containers must use (and possibly write)
> non-standard containers?
>
> Would it be possible to expose the standard containers via a different
> namespace, so they can be used to gather statistics?
>
> e.g.__gnucxx_not_profiled::vector would be a std::vector-compatible
> type (based on the same code) without profiling support, that could be
> used to gather statistics about std::vector use - is that possible, or
> have I misunderstood what you meant?
>

I hope I did not explain the issue well, because I don't understand
your answer well :).
The actual problem that I encountered goes like this:

User code calls std::__profile::vector<int>::operator[].
The instrumentation of vector<>::operator[] calls
std::__norm::unordered_map<...>::insert for bookkeeping.
This in turn requires allocation of memory.
(New/malloc has been hijacked by an external mechanism to compute statistics.)
Malloc instrumentation code calls
std::__profile::vector<int>::operator[], which closes the loop.

The problem is this back arc from the malloc instrumentation code to
std::__profile.
The right TODO here is for std::__profile to use a custom allocator
for its bookkeeping, which would not call malloc at all.
This needs to be fixed and I am planning to do it, but don't want this
issue to hold the branch merge, since it does not apply to the general
case.

> Just my two (not a libstdc++ maintainer) cents,
>
> Jonathan
>

Thank you!
Silvius