[PATCH] gcov: use mmap pools for KVP.

[Martin Liška]

PING^1

On 1/25/21 1:51 PM, Martin Liška wrote:
> On 1/22/21 3:33 PM, Jan Hubicka wrote:
>>>> It is definitly doable (gcov machinery is quite flexible WRT having more
>>>> types of counters).
>>>
>>> Yes, that would introduce back the dropped TOPN counters which I intentionally
>>> dropped.
>>
>> We could bring back topn counters or the easier dominating vlaue ones
>> and add command line option.  However perhaps better in long term would
>> be keep adding mmap ifdefs for targets where it is important...
>>
>> Kernel guys seems to be getting on profile feedback with clang, so we
>> should keep in mind posibility of supporting that as well.
> 
> Sure, that should not be so difficult. They should handle it in their kernel
> run-time.
> 
>>>
>>>>   We could however also ask users to either resort to
>>>> -fno-profile-values or implement mmap equivalent ifdefs to libgcov if
>>>> they really care about malloc profiling.
>>>
>>> Seems reasonable to me.
>>>
>>> Well, the current approach makes some assumptions on mmap (and malloc), but
>>> they seem reasonable to me. I don't expect anybody building Mingw Firefox PGO build,
>>> it's likely unsupported configuration.
>>
>> It is possible to build Firefox with mingw on windows and I would
>> expected feedback to work.
>> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_Mozilla_With_Mingw
>> However this is not only about Firefox - we notice problems with Firefox
>> since it is only real word app where we look at PGO more systematically.
>> But we definitly should aim for PGO to be useful for apps of similar
>> complexity.  It would be nice to incrase this testing coverage.
> 
> I see.
> 
>>
>>>
>>> Another observation about the tcmalloc 'malloc' implementation. It hangs in a PGO build,
>>> but libgcov would be happy if NULL would be returned.
>>
>> Yep, I would expect other folks to try to PGO optimize malloc
>> implementations an we could run into variety of issues...
> 
> Ok, can we go with the suggested mmap patch for now?
> 
> Thanks,
> Martin
> 
>>
>> Honza
>>>
>>> Martin
>>>
>>>>
>>>> So personally I do not see this as a must feature (and I think Martin
>>>> was really looking forward to drop the former topn profile
>>>> implementation :)
>>>>
>>>> Another intersting case would be, of course, profiling of kernel...
>>>>
>>>> Honza
>>>>
>>>
>