We are getting a bugtail of AOT bugs related to static fields in java/lang/invoke/MethodHandleImpl (JDK-8354840, JDK-8353330)

The root cause is AOT-cached method handles can refer to some of the static fields in MethodHandleImpl or its inner classes. In the production run, if the value of these static field changes, we may have unexpected behavior related to identity of objects in these static fields. cdsHeapVerifier makes a very conservative check for such static fields, but usually gives false positives (as in the above two JBS issues)

Proposal:

A long term goal for Project Leyden is to make the JDK library classes "friendly" to AOT initialization. Therefore, this RFE can be one of the initial steps:

- Let C be MethodHandleImpl, or a (direct or indirect) inner class of MethodHandleImpl
- If C was initialized during the AOT assembly phase, store C in the AOT cache in the initialized state. I.e., all of the static fields in C will preserve their values as at the end of the assembly phase. These fields will not be initialized again during the production run.