On Thu, Jan 05, 2023 at 07:49:38PM +0000, DLearner via Digitalmars-d-learn wrote:
> Suppose there is a D main program (not marked anywhere with @nogc),
> that _both_
> 
> A: Calls one or more C functions that themselves call malloc/free; and
> also
> B: Calls one or more D functions that themselves call malloc/free via
> `import core.stdc.stdlib;`
> 
> Assuming the malloc/free's are used correctly, does this situation risk crashing the D main program?
[...]

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.


T

-- 
Маленькие детки - маленькие бедки.

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.