Permalink
Reply
Well, this last week I was playing using malloc/free to do some @nogc code, and using the std.experimental.allocator API. Also, I was trying to see a way to profile my code and search for memory leaks, etc...
What I initially did, was implementing my own allocator API plus my own mallocator, seeing how ECS buble engine does this.
Later, I take a look how std.experimental.allocator API works and I ended writing my own wrapper above make, makeArray, dispose, expandArray & shrinkArray that implements this profiler/stats, and using std.experimental.mallocator .
Finally, I catch that I can only use my wrapper on my code, and that I couldn't use on other third party libraries that allow to use allocators (like EMSI Containers), because (obviously) uses the std.experimental.allocator API.
Then, I discover std.experimental.allocator.building_blocks.stats_collector that looks that does what my littler profiler does, and more. But I see tiny detail that I don't see totally ok.
The stats that are reported by reportPerCallStatistics, shows the file & line number of the allocator!
Like this :
/usr/include/dmd/phobos/std/experimental/allocator/package.d(1585): [numAllocate:1, numAllocateOK:1, bytesAllocated:40]
This could be useful for someone writing his own allocator, but it's pretty useless for anyone trying to track where a memory leak originated in his own code!
On my wrapper, What I did was to have a string file = __FILE__, int line = __LINE__ parameters append to the make, makeArray, dispose, etc... functions and uses the file and & line to record where something was allocated/deallocated/reallocated.
So, why std.experimental.allocator API not does something similar to this ? The allocator implementations, would need to pass & ignore these two additional parameters. Except StatsCollector that can use it to show where the allocation/deallocation/reallocation it's happening
