[PATCH] D50782: [XRay][compiler-rt] Avoid InternalAlloc(...) in Profiling Mode

[Eizan Miyamoto via Phabricator via llvm-commits]

eizan added a comment.

In https://reviews.llvm.org/D50782#1202492, @dberris wrote:

> In https://reviews.llvm.org/D50782#1202318, @eizan wrote:
>
> > I'm trying to understand the memory allocation/deallocation dynamics of this module. It looks like all of the Array<...> objects only have their memory allocation increase because the XRay segmented array doesn't support having its allocation shrink.
>
>
> The `Array<...>` objects only grow, yes, but we're able to trim them and re-use the memory that's in the internal freelist for the array segments.
>
> > However, the memory buffers that each cell in ProfileBuffers point to do get deallocated inside serialize(). Is this correct? Why are these buffers special that they should be deallocated rather than kept around for reuse later like all the other memory?
>
> The actual buffers are obtained through mmap, and they are not fixed-size -- the size of the buffers are dependent on how large the serialised version of the function call tries will be. We can't re-use these buffers across multiple profile collection sessions. The `ProfileBuffers` array hosts structs that are fixed-size (it's a pointer and a size).
>
> Note that in the `reset()` function, we destroy the allocators and re-initilize them (through placement new). The static storage for the allocators and the arrays get effectively re-used, without having to reach for memory from the heap (all of the storage for the `Array<...>` instances will be obtained through the `Allocator<...>` instances). If you look at `Allocator<...>`, the destructor will return the memory to the system as well.


When/how often does serialize() get called during runtime? Should we be worried about making a number of munmap/mmap system calls while the task being profiled is running?


https://reviews.llvm.org/D50782