Echoing what Vic and Dmitry have mentioned. GARCOL cleans up large KILLs, so it's a database operation. Your post seems to ask a different question, akin to Java object garbage collection.
I've been quite surprised to see how much work gets done by IRIS processes with scant process memory; I suppose because it's so easy to use globals.
Understanding what you are experiencing and trying to do would help a lot.
I ran a quick test, Luis, on my Windows 10 laptop with 32GB of memory. Memory usage peaked at about 25GB and settled down to about 20GB. When I deleted the container and stopped Docker, memory went down to about 10GB used.
I did not see obvious memory exhaustion in what is an informal test. I don't have a good sense of what "good" memory usage should be like on this image. If this is causing you trouble, reach out to WRC and they can get you more help.
The error messages that reference port 2188 (the default ISCAgent port) suggest that the previous answers found the culprit. If the backup member cannot communicate with the original primary, it will not failover unless you force it. The software cannot determine whether the primary has failed (in which failover is the correct action) or the backup has been disconnected from the network and the primary is fine (in which failover is incorrect -- this causes both members to act as primary).
If you've resolved this, please post. As Vic said, if this is urgent, contact WRC. Longer term, you might consider upgrading, as there have been many mirroring improvements since 2015.