To piggyback off this, the initial way to run IRIS under a certain user is to use setserviceusername:

As far as I know you can then update the credentials from services as suggested above, but you may want to keep in mind using setserviceusername if you run into other credentials / Windows permission style issues.

Documentation shows that Java 8 and 11 are supported.

11 support was added briefly before Java 17 LTS was released (early 2021 I believe), but it seems InterSystems' Java support has not been updated in the past 2 years. This is something we are working on, however I don't know when that change might be released.

The garbage collector is somewhat an internal process which is why I believe it is sparsely documented. I'd echo Dmitry that understanding your concern would help.

I think what is documented generally covers a high level understanding - that being that there is a GARCOL process. And that blocks are marked freed after a large kill by this process, to be freed in the background.

"Deadlock" is too broad to describe any possibility that could cause the instance to hang. I would recommend reaching out to the WRC/support when that occurs so they can analyze the system with you.

FWIW the first place I would look would be the messages.log which would point to next investigative steps. Alexander's IRIShung suggestion is also a good one.

I agree with Lorenzo and Pietro as well! Since I believe you're looking to run tasks/code that has to do with your mirror failing over, I suppose it might be worth taking a higher level look at the scenarios you are hoping to address. Probably most of the things you want to do can be put in your ZMIRROR so that when your new primary takes over it can do whatever miscellaneous non-IRIS failover tasks you want.

What procedures do you need to be concerned about in a clean failover via shutting down the instance (triggering ZSTOP) vs in an unclean failover for whatever reason, in which case you would only expect your ZMIRROR to run?