GC.sizeOf(array.ptr)

[Dicebot via Digitalmars-d]

On Tuesday, 30 September 2014 at 17:28:02 UTC, Sean Kelly wrote:
> On Tuesday, 30 September 2014 at 15:46:54 UTC, Steven
> Schveighoffer wrote:
>>
>> So I made the call to put it at the beginning of the block, 
>> which obviously doesn't change, and offset everything by 16 
>> bytes to maintain alignment.
>>
>> It may very well be that we can put it at the end of the block 
>> instead, and you can probably do so without much effort in the 
>> runtime (everything uses CTFE functions to calculate padding 
>> and location of the capacity). It has been such a long time 
>> since I did that, I'm not very sure of all the reasons not to 
>> do it. A look through the mailing list archives might be 
>> useful.
>
> Yes, a lot of this is an artifact of the relatively simplistic
> manner that the current GC tracks memory.  If large blocks had a
> header, for example, then this could theoretically live there 
> and
> not cause any problems.  As we move towards supporting precise
> scanning, the GC will need to be aware of the types of data it
> holds, and so some portion of the array appendability strategy
> should probably migrate into the GC.  A redefinition of the GC
> interface is many years overdue.  This just needs to be
> considered when it happens.

I decided to add a similar workaround to CDGC for now and fix the 
way it is stored in druntime a bit later :)

On a related note : CDGC D2 port passes druntime test suite 
starting with today (with only shared library tests disabled), so 
initial upstream PR should happen very soon (just need to clean 
up all trace and "omg hax" commits :))