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

[Mike Franklin]

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.

Providing the machinery to make that convenient (compiler 
switches, runtime configuration, etc.) should probably not be in 
the scope of the GSoC project as it is already pressed for time, 
but that should only be a PR away for anyone who considers it a 
priority.

That being said, we recognize that change needs to happen 
gradually to not rock the boat.  Therefore, even when this 
project is complete, it should probably still default to libc 
with a `-preview` switch or something like to allow users to 
opt-in to the D allocator.  Once there is sufficient experience 
in the real world with the D allocator, the defaults can 
potentially be swapped.

This GSoC project will attempt to remove libc as a hard, 
intrinsic dependency in druntime, and reduce it to a platform 
implementation detail.  In other words, druntime will not depend 
on libc, but a specific platform's port of druntime might.

Mike