Thread overview
DRuntime: Move Functions from `rt/lifetime.d` to `core.lifetime.d` as Templates
Jun 21, 2023
Teodor Dutu
Jun 21, 2023
RazvanN
Jun 22, 2023
Teodor Dutu
June 21, 2023

Hi,

I am working on converting _d_newarray{U,iT,T} to a template. _d_newarrayU() calls __setArrayAllocLength(), which is defined in rt/lifetime.d. Due to how DRuntime is built, rt/lifetime.d cannot be imported into core/lifetime.d (or core/internal/lifetime.d).

To circumvent this, I also moved __setArrayAllocLength() along with other functions in that call stack such as __arrayStart() to core/lifetime.d. To avoid some linker errors caused by the fact that core/lifetime.d is not compiled into the libdruntime.a as it's only meant to contain templates, I converted __setArrayAllocLength() and the other functions to "empty" templates (with no template arguments) just to see if they work. They do.

So my approach now is to convert these new templates to "real" templates, that use their template argument instead of TypeInfo. This will help use TypeInfo less (and hopefully at some point not use it at all in the runtime) but may lead to a lot of template bloating. To reduce this, it's worth noting that __setArrayAllocLength() only uses TypeInfo to place it at the end of the allocated array. Therefore, the template implementation can be split into a small template (that only handles this part) and a larger non-template function that does everything else (which is common for all types).

Do you agree with this approach or do you have other suggestions?

Thanks,
Teo

June 21, 2023

On Wednesday, 21 June 2023 at 03:54:16 UTC, Teodor Dutu wrote:

>

So my approach now is to convert these new templates to "real" templates, that use their template argument instead of TypeInfo. This will help use TypeInfo less (and hopefully at some point not use it at all in the runtime) but may lead to a lot of template bloating. To reduce this, it's worth noting that __setArrayAllocLength() only uses TypeInfo to place it at the end of the allocated array. Therefore, the template implementation can be split into a small template (that only handles this part) and a larger non-template function that does everything else (which is common for all types).

  1. Can we get rid of putting typeinfo in the array or does the GC rely on that?

  2. Why is the larger function a non-template? Shouldn't that also be a template with no template arguments?

June 22, 2023

On Wednesday, 21 June 2023 at 11:52:41 UTC, RazvanN wrote:

>

On Wednesday, 21 June 2023 at 03:54:16 UTC, Teodor Dutu wrote:

>

So my approach now is to convert these new templates to "real" templates, that use their template argument instead of TypeInfo. This will help use TypeInfo less (and hopefully at some point not use it at all in the runtime) but may lead to a lot of template bloating. To reduce this, it's worth noting that __setArrayAllocLength() only uses TypeInfo to place it at the end of the allocated array. Therefore, the template implementation can be split into a small template (that only handles this part) and a larger non-template function that does everything else (which is common for all types).

  1. Can we get rid of putting typeinfo in the array or does the GC rely on that?

  2. Why is the larger function a non-template? Shouldn't that also be a template with no template arguments?

  1. Yes, the GC may use the TypeInfo field, for example to mark indirections for precise GGs. And since allocation functions take a TypeInfo argument, it would be unwise to ignore it.

  2. Right, the larger function can be a template without arguments, but it wouldn't make much of a difference regarding executable sizes or compilation times. Since __setArrayAllocLength() is used for every array (re)allocation, the template is likely to be instantiated (albeit only once) for most D programs.