It would be nice for scanner to figure out thats_processExit is never written to and that it is effectively null readonly field; and then optimize the whole event invocation, includingAppDomain.CurrentDomain call, based on this information. What are the main problems that would need to be solved to make this possible?

I was digging into a compiler-side fix yesterday. The easy fix I tried was to help RyuJIT get rid of this branch.

• We currently don't get rid of it becauseAppContext has a static constructor that cannot be executed at compile time (it allocates a dictionary, for starters).
• Whole program analysis knows the field is effectively readonly, but it doesn't know the value written by cctor (it doesn't know cctor doesn't write anything either). I've added new analysis for static fields that are never written (not even in the cctor):MichalStrehovsky@b32d899.
• This helped get rid ofAppDomain but the damage done to the whole program view could not be undone (we had virtual slots assigned from whole program view that are now unused becauseAppDomain.ToString was gone from the output, but still part of the whole program view). This leaves majority of size savings on the table.

As you say, we need to be able to get rid of this in the scanner. It's too late in RyuJIT.

And we cannot get rid of this in the scanner, because the field is not read only. It can be considered read only once we finish whole program analysis.

We'd need to run whole program analysis twice and then do this substitution when scanning the second time. Running whole program analysis twice is an option. It will be a significant compile throughput regression. We could potentially only do it when optimizing for size/speed and skip it in blended mode?

We'd need to run whole program analysis twice and then do this substitution when scanning the second time.

It does not seem to be worth it.

Here is a variant that leverages the fact that the ProcessExit events is exposed via AppDomain instance fields:main...jkotas:runtime:appdomain . It would work better in case we decide to fix thesender on the FirstChanceException and UnhandledException events. Naot is passing in null as the sender, but Mono is passing in the appdomain instance. Either variant is fine with me. Do you have a preference?

Do you have a preference?

Yours looks much better! GitHub won't let me approve my own PR even though it's all your commit, so LGTM!