Reimplementing software building blocks like malloc and free in D

[Eugene Wissner]

On Sunday, 12 August 2018 at 05:24:56 UTC, Mike Franklin wrote:
> I wasn't aware of Eugene's implementation.  At first glance it 
> looks real nice.  It appears to have some dependencies on other 
> features of his Tanya library, so at a minimum, those will have 
> to be removed or replaced.
>

It depends only on internal libc-free syscalls that can be 
replaced with mmap/munmap and on copy()/copyBackward() that are 
just memcpy and memmove respectively.

> But, how does it perform?  In order to make the case for using 
> these D implementations in druntime, we'll have to gather some 
> metrics on the implementations in terms of performance, memory 
> fragmentation, etc. and ensure they are on par with the C 
> standard library implementations or alternative implementations 
> like jemalloc and tcmalloc?

Some years ago I had a BigInt implementation that allocated and 
deallocated memory like crazy. I compared how it works with 
malloc and my own allocator and my allocator was slightly faster 
than glibc (probably because of thread-safety). But yes, a good 
implementation needs benchmarks which test it systematically 
under various conditions.

Tanya's allocator is also tested only on x86-64 Linux, but is 
trivially to port to Windows and other architectures. I actually 
had a Windows version before but removed it because I was too 
lazy to read msdn.

> Perhaps, with Eugene's permission, you can use his 
> implementation as a base, take some measurements, and see if it 
> can be improved upon with either more features or better 
> performance.

You can use it as reference when implementing something else or 
as a starting point for the further work. Anyway feel free to use 
it as you like.

P.S. In the last weeks I had thoughts to split low-level stuff 
from tanya and put it into a separate library, kind of native, 
gc-free x86-64 (and maybe aarch64) Linux runtime for D. Probably 
I should go for it :)