www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC interaction with malloc/free

reply DLearner <bmqazwsx123 gmail.com> writes:
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?

Best regards
Jan 05 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
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

-- 
Маленькие детки - маленькие бедки.
Jan 05 2023
parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Thursday, 5 January 2023 at 19:54:01 UTC, H. S. Teoh wrote:

 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


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?
Jan 05 2023
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
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.
Jan 05 2023