D on next-gen consoles and for game development

[Rainer Schuetze]

On 31.05.2013 12:54, Michel Fortin wrote:
> On 2013-05-31 06:02:20 +0000, Rainer Schuetze <r.sagitario at gmx.de> said:
>
>> On 30.05.2013 22:59, Benjamin Thaut wrote:
>>>> One possible complication: memory block operations would have to treat
>>>> pointer fields differently somehow.
>>>
>>> Would they? Shouldn't it be possible to make this part of the post-blit
>>> constructor?
>>
>> Not in general, e.g. reference counting needs to know the state before
>> and after the copy.
>
> No. Reference counting would work with post-blit: you have the pointer,
> you just need to increment the reference count once. Also, if you're
> moving instead of copying there's no post-blit called but there's also
> no need to change the reference count so it's fine.
>

I was thinking about struct assignment through copying and then calling 
the postblit constructor, not copy construction. But I forgot about the 
swap semantics involved. If I interpret the disassembly correctly, the 
assignment in

S s1, s2;
s2 = s1;

translates to

S tmp1, tmp2;
memcpy(&tmp1, &s1);
tmp1.__postblit;   // user defined this(this)
s2.opAssign(tmp1); // makes a copy of tmp1 on the stack
//opAssign does:
     memcpy(&tmp2,&s2);
     memcpy(&s2,&tmp1);
     tmp1.__dtor;

There are a number of additional copies of the original structs, but the 
number of constructor/destructor calls are balanced. That should work 
for reference counting.

> What wouldn't work with post-blit (I think) is a concurrent GC, as the
> GC will likely want to be notified when pointers are moved. Post-blit
> doesn't help there, and the compiler currently assumes it can move
> things around without calling any function.

It would not allow to create a write barrier that needs to atomically 
change the pointer at a given location, or at least to record the old 
value before overwriting it with the new value. But that might not 
exclude concurrency, for example a concurrent GC with deferred reference 
counting.