On Thu, Jan 05, 2023 at 08:18:42PM +0000, DLearner via Digitalmars-d-learn
wrote:
> On Thursday, 5 January 2023 at 19:54:01 UTC, H. S. Teoh wrote:
[...]
> > core.stdc.stdlib.{malloc,free} *is* the exact same malloc/free that
> > C uses, it has nothing to do with the GC. The allocated memory is
> > taken from the malloc/free part of the heap, which is disjoint from
> > the heap memory managed by the GC.
> >
> > So, it should not cause any crashes.
[...]
> That's comforting, but there is a reference in:
>
> https://dlang.org/blog/2017/09/25/go-your-own-way-part-two-the-heap/
>
> '...Given that it’s rarely recommended to disable the GC entirely,
> most D programs allocating outside the GC heap will likely also be
> using memory from the GC heap in the same program. In order for the GC
> to properly do its job, it needs to be informed of any non-GC memory
> that contains, or may potentially contain, references to memory from
> the GC heap.'
>
> Followed by things that have to be done (GC.addRange) to avoid
> interaction effects?
You only need to do this if you will be storing pointers to GC-allocated
objects inside malloc-allocated objects. E.g., if you malloc a struct
that contains a reference to a GC-allocated class object.
The reason for this precaution is because the GC needs to know all the
root pointers that eventually may point to a prospective object to be
garbage-collected. If there are pointers to an object outside of the
areas the GC is aware of, e.g., in the malloc heap, then the GC may not
be able to correctly determine that there's still a reference to the
object, and may collect it prematurely, leading to a crash when you next
try to dereference the pointer to the object.
If there are no references from the malloc heap to the GC heap, then you
do not need to use GC.addRange.
T
--
Build a man a fire, and he is warm for a night. Set a man on fire, and he is
warm for the rest of his life.
