As far as I can tell, any usage to a UObject inside blueprint will leave a permanent reference to it. Therefore it can’t be garbage collected.
Ex.
You have an Array of UObjects
You print a single index UObject name
You clear the Array
When Garbage collector executes it will collect all the Uobjects except for the one that was referenced to print. It will be referenced permanently till the BP that was used to print the name is Destroyed.
Is my understanding correct or is there something Im missing?
I think a solution is to only use Uobject references inside of functions, not the Eventgraph
You got it a bit wrong.
When printing some UObjects information in your log, the log takes the UObjects name variable and prints it as a string. After printing the name your log window does not know where the printed string came from and does not hold the UObject from being garbage collected. After you print your UObjects name and your code continues after the print function, the print function completely forgets about your UObject and when your UObject is neither referenced in the array nor anywhere else it should get garbage collected.
If your UObject is neither
- referenced in the current function/event callstack as a temporary or local variable
- referenced as member variables in another UObject or USTRUCT in Blueprint
- referenced by UObject/USTRUCT UPROPERTY() member variables in C++
- added to the root node (obj->AddToRoot() ) in C++
then it should be garbage collected (maybe there are some other edge cases, but these are the general criteria for garbage collection as far as i know)
Using UObjects in Event graphs and functions is perfectly fine, it’s what Blueprint is designed for : To work with UObjects/UStructs. 
I just want to chime in, I’m not exactly sure that @StefanHohnwald’s answer is a 100% true. What I believe he’s missing is that the output of impure nodes are cached and does actually prevent GC. Therefore, if you Print an object, that’s probably fine - until the object comes from a variable or from a pure node. It’s not if it comes from an impure one, like Construct Object.
I’ll attempt to verify today that inputs are actually not cached, while the output is, just to make sure that I’m not stating anything false, but according to my recollection, it’s how it works, and you are right @Flapjack99 that it limits the effective code you can / should put in event graphs.
Cheers!
@KristofMorva. Yes as far as I can tell the Impure node is what causes the issue. The Construct Object node also creates a reference that prevents GC. If the Construct Object is fired from a BP that’s destoyed it’s not a problem though.
@StefanHohnwald is correct as far as I know except for the impure node Reference. To clarify the highlighted outputs are the problem. The print node itself is fine just not the node you use to get the reference.
It’s not the end of the world, just a little annoying and clarity would be nice
Thanks
