• "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> (6/6) Aug 07 2015 Is the current Phobos GC smart enough to *not* scan GC-allocated
• David Nadlinger (4/7) Aug 07 2015 Yes (mostly). Have a look at the NO_SCAN attribute (and similar)
• deadalnix (3/10) Aug 07 2015 This attribute exists, but how much grinding in the type system
• rsw0x (6/18) Aug 07 2015 Not a whole lot IIRC.
• Steven Schveighoffer (12/16) Aug 07 2015 Mainly legacy. The D runtime was all runtime before 'druntime' was
• rsw0x (10/30) Aug 09 2015 After taking a bit of time to review, I'm actually disappointed
• David Nadlinger (4/6) Aug 07 2015 See

"Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:

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?

"David Nadlinger" <code klickverbot.at> writes:

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

"deadalnix" <deadalnix gmail.com> writes:

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 ?

"rsw0x" <anonymous anonymous.com> writes:

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?

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

"rsw0x" <anonymous anonymous.com> writes:

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.

"David Nadlinger" <code klickverbot.at> writes:

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/maste
/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