Proposal: use progressive JIT to remove init checks on static classes after static constructor is known to have run #12697
Description
Currently the runtime takes a lock surrounding external access to a class that contains any static constructor (whether written explicitly or implicitly). Those locks add up to substantial runtime cost, especially on frequently accessed classes.
Since we have progressive JIT in the CLR now, there is an opportunity to swap out the code that executes with more efficient code that removes the locking once the static constructor is known to have been initialized. (For example, the first pass JIT code containing the static lock could contain a final instruction to trigger the re-JIT to remove the init locks. So that way, when the static constructor runs, it could trigger the code generation + swap logic.)
I would prefer to have that implemented in such a way that doesn't affect debugging -- we'll only hit the static constructor once in any case, so I suspect this would be safe to do even on CLI modules compiled without the optimization flag.
I did a quick check of existing issues and I don't see anything obviously related... Please let me know if this has already been addressed or discussed.