Is the current Phobos GC smart enough to *not* scan GC-allocated arrays when the elements don't contain any indirections (references/pointers).

If not how difficult would it be to fix this? There are bunch of traits in Phobos that check for this. If these were moved to druntime I guess they could be reused in GC-implementation, right?

On Friday, 7 August 2015 at 12:05:01 UTC, Per Nordlöw wrote:
> Is the current Phobos GC smart enough to *not* scan GC-allocated arrays when the elements don't contain any indirections (references/pointers).

Yes (mostly). Have a look at the NO_SCAN attribute (and similar) in the druntime docs.

 — David

On Friday, 7 August 2015 at 12:17:19 UTC, David Nadlinger wrote:
> On Friday, 7 August 2015 at 12:05:01 UTC, Per Nordlöw wrote:
>> Is the current Phobos GC smart enough to *not* scan GC-allocated arrays when the elements don't contain any indirections (references/pointers).
>
> Yes (mostly). Have a look at the NO_SCAN attribute (and similar) in the druntime docs.
>
>  — David

This attribute exists, but how much grinding in the type system dmd and the runtime are doing ?

On Friday, 7 August 2015 at 17:23:18 UTC, deadalnix wrote:
> On Friday, 7 August 2015 at 12:17:19 UTC, David Nadlinger wrote:
>> On Friday, 7 August 2015 at 12:05:01 UTC, Per Nordlöw wrote:
>>> Is the current Phobos GC smart enough to *not* scan GC-allocated arrays when the elements don't contain any indirections (references/pointers).
>>
>> Yes (mostly). Have a look at the NO_SCAN attribute (and similar) in the druntime docs.
>>
>>  — David
>
> This attribute exists, but how much grinding in the type system dmd and the runtime are doing ?

Not a whole lot IIRC.

Probably a question for Martin Nowak as he seems to do a lot of the GC work - but I'm curious why the GC takes basically zero advantage of D's compile time magic(allocations are funneled through a C API,) is it because build times would be too slow?

On Friday, 7 August 2015 at 17:23:18 UTC, deadalnix wrote:
> This attribute exists, but how much grinding in the type system dmd and the runtime are doing ?

See https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d. The bits in ti.flags and ClassInfo that are tested there to set NO_SCAN should be emitted correctly by the compiler.

 — David

On 8/7/15 1:38 PM, rsw0x wrote:

> Probably a question for Martin Nowak as he seems to do a lot of the GC
> work - but I'm curious why the GC takes basically zero advantage of D's
> compile time magic(allocations are funneled through a C API,) is it
> because build times would be too slow?

Mainly legacy. The D runtime was all runtime before 'druntime' was included, not much compile time introspection. All the hooks to the GC were done via calls with the compiler passing the TypeInfo to the appropriate pre-defined hook.

I think we have much more tools available and greater experience these days, it would be nice for all compiler hooks that do any runtime calls (except for possibly intrinsics) to simply be rewrites to call templates that do the right thing.

The main barrier that I can tell is that the compiler takes liberties in regards to const/pure/etc. that library code cannot take.

-Steve

On Friday, 7 August 2015 at 18:29:05 UTC, Steven Schveighoffer wrote:
> On 8/7/15 1:38 PM, rsw0x wrote:
>
>> Probably a question for Martin Nowak as he seems to do a lot of the GC
>> work - but I'm curious why the GC takes basically zero advantage of D's
>> compile time magic(allocations are funneled through a C API,) is it
>> because build times would be too slow?
>
> Mainly legacy. The D runtime was all runtime before 'druntime' was included, not much compile time introspection. All the hooks to the GC were done via calls with the compiler passing the TypeInfo to the appropriate pre-defined hook.
>
> I think we have much more tools available and greater experience these days, it would be nice for all compiler hooks that do any runtime calls (except for possibly intrinsics) to simply be rewrites to call templates that do the right thing.
>
> The main barrier that I can tell is that the compiler takes liberties in regards to const/pure/etc. that library code cannot take.
>
> -Steve

After taking a bit of time to review, I'm actually disappointed in how allocations are handled. The compiler emits 10(!) different runtime calls depending on the allocation. This really seems like something that could be handled far better in the runtime itself, and reduce compiler complexity. But I really don't know enough to say that.

There's some serious non-negligible overhead per allocation here AFAICT.