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

[Dean Michael Berris via Phabricator via llvm-commits]

dberris added a comment.

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.



================
Comment at: compiler-rt/lib/xray/xray_profile_collector.cc:64
+
+// These need to be global aligned storage to avoid dynamic memory.
+static typename std::aligned_storage<sizeof(FunctionCallTrie::Allocators)>::type
----------------
eizan wrote:
> Do you mean dynamic memory allocation? Why does alignment affect whether it's done?
I meant dynamic initialisation. The alignment is important so that the pointers we get when we reinterpret-cast will be of the expected alignment for an object of an appropriate size. We need that to make the placement new calls have well-defined semantics (and the pointer is appropriately aligned).

We need this to be global program-duration (static) storage only, because we want to avoid relying on C++ ABI functions for registering dynamic initialisation and de-initialisation (constructor and destructor) routines.


https://reviews.llvm.org/D50782