std.experimental.allocator API and nearly useless StatsCollector

[Andrei Alexandrescu]

On 6/20/21 11:49 AM, Luis wrote:
> 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

If I understand the problem correctly, in order for statsCollector to 
work, it needs to be at the "top" of the allocator type tree. The design 
indeed does not support line numbers when statsAllcator is inserted 
somewhere in the middle.