If a JIT job sees a @Stable variable in the uninitialized state, it treats it as a normal variable.

In the future, when that variable is set, and the JIT runs again, it will be able to constant-fold the value of the variable.

Perhaps a handshake like this would be helpful:

1. The JIT checks a stable variable, and notes it is not foldable yet; perhaps the JIT also determines heuristically that if it DID have a foldable value, that would be profitable somehow. The JIT commits the code, but with a dependency on the variable.

2. The VM tracks the stable variable on the JIT's behalf. When the variable changes, the compiled method is queued for another pass of the JIT.

3. The JIT queue appropriately flow-controls and prioritizes such recompilations. They are speculative in nature, but over time it may be profitable to do them.

4. In an AOT setting, it might be worth AOT-caching both versions of the code, and using the dependency mechanism (from step 2) to time the installation of the better version.

For stable arrays, there is no simple and direct way to track array element writes. But the read of the array can be tracked, and the VM can have a background task, hinted by such reads, or simply put on a repeating timer, to occasionally recheck the array elements. In that way, JIT code could have dependencies on stable array elements, as well as on the stable fields themselves.