[GSoC] 'Independency of D from the C Standard Library' progress and update thread

[sarn]

On Sunday, 2 June 2019 at 00:10:51 UTC, Mike Franklin wrote:
> On Saturday, 1 June 2019 at 02:40:10 UTC, sarn wrote:
>
>> Here's something to consider if you're replacing malloc() et 
>> al: it's popular (especially with large server deployments) to 
>> tune application memory allocation performance by replacing 
>> libc malloc() with alternatives such as tcmalloc and jemalloc.
>>  That works because they use the same libc malloc() API but 
>> with a different implementation, injected at link or load time 
>> (using LD_PRELOAD or something).
>>
>> It would be great if D code can still take advantage of 
>> alternative allocators developed by third-parties who may or 
>> may not be writing for D.
>
> std.experimental.allocator 
> (https://dlang.org/phobos/std_experimental_allocator.html) 
> supports an `IAllocator` interface 
> (https://dlang.org/phobos/std_experimental_allocator.html#IAllocator).
>
> The way I envision this playing out is that when 
> std.experimenal.allocator is ported to druntime, callers would 
> use the `IAllocator` interface.  Therefore, any allocator 
> conforming to that interface could potentially serve as 
> druntime's allocator.  In order to swap the allocator, one 
> would only have to implement the `IAllocator` interface, 
> potentially even using the `Mallocator` 
> (https://dlang.org/phobos/std_experimental_allocator_mallocator.html), and make the swap.

Thanks, that makes sense.  It sounds like a version spec that 
switches to Mallocator (or whatever) could do it, as long as it 
doesn't force a recompilation of the whole runtime library.  
(Even more convenient would be a runtime flag like --DRT-gcopt, 
but I'm guessing you'd want to make it happen at compile time.)