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.
