[PATCH] D68351: [profile] Add a mode to continuously sync counter updates to a file

[Vedant Kumar via Phabricator via llvm-commits]

vsk added a comment.

In D68351#1691934 <https://reviews.llvm.org/D68351#1691934>, @sajjadm wrote:

> In D68351#1691915 <https://reviews.llvm.org/D68351#1691915>, @vsk wrote:
>
> > In D68351#1691883 <https://reviews.llvm.org/D68351#1691883>, @sajjadm wrote:
> >
> > > Not sure it belongs in this CL specifically, but would it be possible to later add a mode that defers the initialization of the mmap'd file until specifically requested by the process?
> >
> >
> > This sounds tricky to me, as the initialization requires some work to be done in each copy of the profile runtime linked into the process.
> >
> > Could you clarify whether you're referring to processes which use the profiling runtime's static initializer, or not? My understanding is that for processes which //do// use the runtime's static initializer, it's always desirable to set up the mmap'd file in that initializer. If that's not true, I'd appreciate a counterexample. For processes that //don't// use the runtime's static initializer, the situation (at Apple, at least) is typically that it's a kernel extension or bare-metal piece of firmware, and the continuous mode isn't really applicable anyway.
>
>
> We do use the static initializer, but in our use case the process doesn't necessarily know where to write coverage data until some other application-specific code has run.


I see, thanks for explaining.

> Ideally, I would like to be able to have the instrumented process receive a shared memory buffer from another process, do continuous profile sync into that memory region, and not care whether it is file-backed or anonymous mapping. So it would be great if application code could give the runtime some sort of handle to that object [1] and tell the runtime to use that space for profiling.

I see. Is the lack of support for value profiling a concern, or would this just be for code coverage?

Regardless, I think it's possible to achieve this. If `__llvm_profile_set_file_object` is called in every copy of the profile runtime in a process, only minor changes to this patch would be required [1]. Judging by how `setProfileFile` is implemented, I suspect this is the case. If not, a much more invasive change would be needed.

[1] You could do this by recognizing a "%dc" filename pattern for "delayed continuous sync" mode (or some equivalent). The static initializer would detect this and defer the mmap() initialization. Later, when `__llvm_profile_set_file_object` is called, continuous mode can be initialized.

> [1] This could be just a pointer to a buffer that the application has already mmap'd, or it could be a file descriptor that the runtime is responsible for calling mmap on. Not sure which one would make more sense.

I'm not sure it's possible to mmap() the contents of a section using MAP_FIXED over another non file-backed VM region. You may need to experiment with this.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68351/new/

https://reviews.llvm.org/D68351