Documentation is very scarce about engine internals

[qiqian82]

@Richard Hinckley;528860

Thanks for your question, qiqian82. We are working on some expansion of the GC documentation, but it might not go to the degree of technical depth you are describing in the immediate future. I’m not sure exactly what you’re asking about on-stack root references, but if you can clarify it, I can get you an answer. As for cyclic references, the reflection system generally handles them before they get to GC. For example, if I create two actors in a level that point to each other via a BP variable, storage class pointer (TArray, TWeakPtr, etc.), or UPROPERTY, then call Destroy() on one of them, it will be destroyed. The other actor’s pointer variable will be set to NULL in this process. When GC comes around, there is no longer a cycle because of the pointer being set to NULL, so the destroyed actor can be freed. GC in general is designed to work without the user getting involved in it, but for some projects it may be helpful. If there’s a more specific question you have, I can look into it for you, but as I mentioned earlier, there are some GC documentation updates in production.

Thanks for your explanations.

So if I declare 2 UObject subclasses with refereances to each other, one of them should be TWeakPtr
What if I create 2 blueprint class, which have references to each other ? I couldn’t find a way to declare variables in blueprint to be “Weak”

Now about the “root”. Typically GC scans object references from some "root"s, like static variables in classes, variables in thread-stack, it’s a recursive process until all reachable objects are scanned, all remaining unscanned objects are garbage.
What I see in UE4 is, UE4 allocate all objects into a big array, some objects might be flagged as “root”, when UE4 try to collect garbage, it scans the whole array, not only “root” objects in this array. Do so means, it will scan into unreachable objects, it’s a wasting of CPU cycles, also bring trouble to handle cyclic references.