On Saturday, 11 August 2018 at 18:59:00 UTC, Aruna Maurya wrote:
1. If it would have been C++, the above can be implemented by
using the mmap() syscall to allocate memory
from the heap. However, something that I am not able to
understand in the idea description is 'runtime hooks'.
The compiler recognizes certain expressions and lowers them to
functions in the D runtime that we call runtime hooks. See
https://wiki.dlang.org/Runtime_Hooks for an unmaintained, but
still relevant, list of some of them.
For example, the expression `cast(int)a`, where `a` is an array
of another type will get lowered to `_d_arraycast`.
We're trying to rewrite many of these hooks as templates. D has
changed quite a bit over the past few years, and at the time the
existing runtime hooks were written D didn't have templates and
many other features. See
https://github.com/dlang/druntime/pull/2264 for an example
converting `_d_arraycast` to a template.
Many of the existing runtime hooks leverage software building
blocks like `memcpy`, `memcmp`, `malloc`, `free`, etc. in their
implementation. If the runtime hooks are implemented as
templates, we will have access to the type information and other
information at compile-time rather than run-time. This will give
us opportunities to specialize implementations at compile-time.
See https://github.com/JinShil/memcpyD/blob/master/memcpyd.d for
a proof of concept exploring such opportunities for `memcpy`.
2. Also as far as I can understand, this idea is about
implementing the above from scratch, and not tweaking the
existing codebase. Do let me know if I am wrong.
I'm the one who proposed the idea, and, yes, I envisioned
implementing these building blocks from scratch, translating an
existing implementation from another language (watch the
license!), or implementing an existing published algorithm in D.
There might even be a way to leverage implementation code in
https://dlang.org/phobos/std_experimental_allocator.html, but if
that code were used in the D runtime, it couldn't have
dependencies on Phobos (D's standard library), so it'd probably
have to be modified to make it free-standing. I don't know,
though, I haven't looked into it in any detail.
I didn't envision the participant modifying any existing code.
In the case of `malloc`, `realloc`, and `free`, I'd just like to
have an idiomatic D implementation that we might be able to
leverage when re-implementing the runtime hooks as templates so
we no longer have to depend on the C standard library. I think
implementing them in D will make D more portable to other
platforms, including freestanding bare-metal platforms like
operating systems or microcontrollers, and D's unique feature set
may provide opportunities to improve upon existing
implementations in terms of performance and compile-time
It's difficult for me to articulate all this, as it's a complex
vision in my head, so if the above just raised more questions,
Also see https://wiki.dlang.org/Memory_Management for some
perspective, especially if you're new to D.
The ideas on the wiki page are just to plant the seeds of
creativity. Feel free to deviate from the idea as you wish, or
submit a proposal formulated from your own ideas.