This RFE is created to track one potential design of JDK-8293336.

When AOT-caching resolve indy call sites, we have to cache many objects in the java.lang.invoke package (MethodType, MethodHandle, etc). Classes in java.lang.invoke have complex relationship with each other and *may* assume a specific initialization order.

In order to faithfully reproduce the results of indy resolution, it's desirable to capture the entire (initialized) state of the java.lang.invoke package and store that into the AOT cache. Otherwise, if we allow (some or all of) the <clinit> methods in in j.l.i to run again in the production run:

- the classes may be initialized in a different order than in the training run, resulting in subtle errors.
- some cached objects may point to a static field that was initialized during the assembly phase, but that static field may be assigned a different value during the production run

===================

Proposal:

- Scan all the cached indy call sites and find all reachable object instances. Mark the classes of these objects as aot-initialized.
- Also add other classes (e.g., j.l.i.MethodHandles) which don't have any cached instances, but whose static fields may be pointed to by the cached objects.