FYI - mo' work on std.allocator

[Brian Schott via Digitalmars-d]

On Wednesday, 7 May 2014 at 09:47:44 UTC, John Colvin wrote:
> On Wednesday, 7 May 2014 at 09:29:15 UTC, Brian Schott wrote:
>> On Wednesday, 7 May 2014 at 08:22:51 UTC, John Colvin wrote:
>>>> The allocator version uses 1/3 the memory that the older GC 
>>>> version used.
>>>
>>> What is your feeling on the increased code 
>>> complexity/fragility, if any?
>>
>> It was difficult because it's very easy to accidentally have 
>> references to GC memory that the GC doesn't know about. When 
>> the GC starts freeing "live" memory you get all sorts of 
>> contract and invariant violations that should never be 
>> possible.
>
> You mean holding references to GC data in a NO_SCAN block?

I wasn't using GC.malloc, I was using Mallocator from the new 
std.allocator. There were several tricky cases like a struct that 
was allocated with malloc containing an array of pointers field. 
Each element of the array was allocated with malloc, but the 
array of pointers itself came from a map-filter-array chain 
somewhere deep inside the code. The GC would free the array while 
leaving the containing struct corrupted and the elements of the 
array unreachable.