One awesome GC feature we will use in Mir!

[Petar]

On Tuesday, 18 September 2018 at 23:01:46 UTC, Per Nordlöw wrote:
> On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote:
>> I just remember that D's GC has NO_SCAN [1] attribute!
>
> I thought D libraries like Mir and Lubeck only had to care 
> about when to call GC.addRange after allocations that contain 
> pointers to GC-backed storage and GC.removeRange before their 
> corresponding deallocations. But that's perhaps only when using 
> non-GC-backed allocators (not using new), right?

GC.addRange and GC.removeRange are necessary to mark memory 
blocks allocated outside of the GC when they may contain pointers 
to memory allocated by the GC.

For example, if you have a @nogc container, the array backing the 
container can allocated vie libc's malloc. The users are free 
push elements allocated by the GC on this container, so to be 
safe, the container must use GC.addRange to tell the GC that the 
array may point to such elements. When the array grows, shrinks 
or the whole container is destoryed, the array needs to be passed 
to GC.removeRange, so the GC would be prevented from scanning 
freed memory.

When you use the GC it automatically does the book keeping for 
you. It's only when you manually manage memory that you need to 
be careful whether this memory points to GC objects.