On Tuesday, 30 September 2014 at 17:51:18 UTC, Steven
Schveighoffer wrote:
> On 9/30/14 1:23 PM, Sean Kelly wrote:
>
>> (except for the
>> definition of the APPENDABLE BlkAttr, which really should be
>> defined externally and within the user-reserved range of the
>> bitfield instead of the GC-reserved range, but I digress...)
>
> The APPENDABLE bit was added as a solution to avoid having to reserve that memory for all allocations. Basically, if you try to append to a block that doesn't have the bit, it simply reallocates conservatively.
>
> So it does have to be part of the GC metadata, because the most important effect is on blocks that AREN'T allocated via the array runtime. Otherwise, the append mechanism creeps into all aspects of memory allocation.

Yeah I know.  But when I defined the BlkAttr bitfield I'd
reserved one portion of the range for internal GC stuff and
another portion for user-defined stuff.  APPENDABLE should
probably have landed in the user-defined portion.  I don't see
any of those comments in the current code or I'd point to them.
I guess they were deleted at some point.

On 9/30/14 2:19 PM, Sean Kelly wrote:
> On Tuesday, 30 September 2014 at 17:51:18 UTC, Steven
> Schveighoffer wrote:
>> On 9/30/14 1:23 PM, Sean Kelly wrote:
>>
>>> (except for the
>>> definition of the APPENDABLE BlkAttr, which really should be
>>> defined externally and within the user-reserved range of the
>>> bitfield instead of the GC-reserved range, but I digress...)
>>
>> The APPENDABLE bit was added as a solution to avoid having to reserve
>> that memory for all allocations. Basically, if you try to append to a
>> block that doesn't have the bit, it simply reallocates conservatively.
>>
>> So it does have to be part of the GC metadata, because the most
>> important effect is on blocks that AREN'T allocated via the array
>> runtime. Otherwise, the append mechanism creeps into all aspects of
>> memory allocation.
>
> Yeah I know.  But when I defined the BlkAttr bitfield I'd
> reserved one portion of the range for internal GC stuff and
> another portion for user-defined stuff.  APPENDABLE should
> probably have landed in the user-defined portion.  I don't see
> any of those comments in the current code or I'd point to them.
> I guess they were deleted at some point.

Hm... looked at the code, I have no idea how the GC would handle user-defined stuff. It seems to only deal with bits it knows about (i.e. APPENDABLE is specifically handled in gc/gc.d)

I think I just took the next bit available, if there was a warning about GC internal bits when I added APPENDABLE, I either missed it or dismissed it.

-Steve

On Tuesday, 30 September 2014 at 19:19:18 UTC, Steven
Schveighoffer wrote:
>
> Hm... looked at the code, I have no idea how the GC would handle user-defined stuff. It seems to only deal with bits it knows about (i.e. APPENDABLE is specifically handled in gc/gc.d)

It wouldn't.  The GC was just going to provide storage for some
number of user-defined bits.


> I think I just took the next bit available, if there was a warning about GC internal bits when I added APPENDABLE, I either missed it or dismissed it.

With BlkAttr defined independently in a bunch of different places
at the time, the comment would have been easy to miss.  I don't
know that it really matters anyway, but it's something I noticed
today.

On Tue, 30 Sep 2014 17:43:04 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> 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 :))
wow! no, really, what else can i say? ;-)