RFR: 8230912 [lworld] InterpreterRuntime::uninitialized_static_value_field fails with fatal error: An exception should have been thrown above

[Frederic Parain]

Please review this fix for JDK-8230912

CR:
https://bugs.openjdk.java.net/browse/JDK-8230912

Webrev:
http://cr.openjdk.java.net/~fparain/8230912/webrev.00/index.html

The issue comes from the attempt to relax constraints on circularity for
static inline fields. In JDK-8229372, static inline fields where initialized
to their default value, by the JVM, in step 8 of the class initialization
process.

The problem is the access to the static inline fields of a class when this
class is being initialized.

For instance:

    class A {
        static B b;
        static C c;
    }

    inline class B {
        static {
            C c = A.c;
        }
    }

    inline class C { }


During the initialization of A, the JVM will try to initialized its static field b,
which will trigger the initialization of class B. But the initialization of B requires
the execution of its static initializer which accesses the field A.c which might not
be initialized yet.

The proposed solution is to allow the initialization thread of class to access the static
inline fields of the class being initialized even if they are not initialized yet, the JVM
will perform an on-demand initialization on these cases.

Access to these uninitialized static inline fields will still be forbidden for threads that
are not the initialization thread, which can only happen when the class failed to initialized
properly.

Another issue with static initializer addressed in this fix is when a static inline field is
initialized by another class static initializer before the JVM initializes it:

   class D {
       static E e;
       static F f;
   }

   inline class E {
       static {
            D.f = new F(5);
       }
   }

   inline class F { … }


In this case, the JVM must detect that the field has already been initialized, and must not
initialize it again to the default value.

All these aspects will have to be specified more formally in the JVMS.

The new unit test tries to check all the semantic above, and also covers more error cases.

Thank you,

Fred