Issue store-store barrier after re-materializing objects during deoptimization

In JDK-8322854 comments [~jrose] wrote:

The JIT might scalar-replace a string, but then generate it onto the heap. (This is for deoptimization, recovery from an uncommon event, previously speculated against.) In that case the JIT generates the string object not by executing code but interpreting debug-info. If that generation process failed to issue a store-store barrier, on a CPU that needed it, and there was no other store-store barrier issued (during the course of deoptimization), then conceivably you might get a race.

I agree. Consider next case where object escapes after deoptimization:

public class Test {
     int _i;
    public static Test _t; // Externally visible static field

    public Test(int i) { _i = i; }

    void test(int i) {
         Test t = new Test(i);
         if (i == foo()) {
            // Rare case so C2 generates uncommon trap.
            // Object 't' does not escape from EA POV since
            // it is referenced only by uncommon trap.
            // It will escape after deoptimization.
            Test::_t = t;
         }
   }
}