Some questions about GC

Roland Hadinger rolandh.dlangforum at maildrop.cc
Fri Oct 18 16:54:55 UTC 2019


These questions probably need some context: I'm working on an 
interpreter that will manage memory via reference counted struct 
types. To deal with the problem of strong reference cycles 
retaining memory indefinitely, weak references or recursive 
teardowns have to be used where appropriate.

To help detect memory leaks from within the interpreter, I'd also 
like to employ core.memory.GC in the following fashion:

* keep core.memory.GC off (disabled) by default, but nonetheless 
allocate objects from GC memory
* provide a function that can find (and reclaim) retained 
unreachable object graphs that contain strong reference cycles
* the main purpose of this function is to find and report such 
instances, not to reclaim memory. Retained graphs should be 
reported as warnings on stderr, so that the program can be fixed 
manually, e.g. by weakening some refs in the proper places
* the function will rely on GC.collect to find unreachable objects
* the function will *always* be called implicitly when a program 
terminates
* the function should also be explicitly callable from any point 
within a program.

Now my questions:

Is it safe to assume that a call to GC.collect will be handled 
synchronously (and won't return early)?

Is there a way to ensure that GC.collect will never run unless 
when called explicitly (even in out of memory situations)?

Is it possible and is it OK to print to stderr while the GC is 
collecting (e.g. from @nogc code, using functions from 
core.stdc.stdio)?

Could I implement my function by introducing a shared global flag 
which is set prior to calling GC.collect and reset afterwards, so 
that any destructor can determine whether has been invoked by a 
"flagged" call to GC.collect and act accordingly?

Alternatively: do I need to implement such a flag, or is there 
already a way in which a destructor can determine whether it has 
been invoked by the GC?

Thanks for any help!


More information about the Digitalmars-d-learn mailing list