BACKGROUND:

Before this RFE, the AOT cache stores "old" classes (InstanceKlass::major_version() < 50) the "unlinked" state, to be verified by the inference verifier at runtime. At runtime, it's possible for such classes to fail verification if some of their verification constraints cannot be satisfied.

E.g., assuming we have created a CDS archive A.jsa that contains the classes OldX, Super, and Sub:

    class OldX { // class file version = 49
        Super get() {
            return new Sub();
       }
    }

During the verification of OldX, the verifier would load Super and Sub to check, and require that Sub is indeed a subtype of Super. Such a requirement is called a "verification constraint" of OldX.

When the application runs with the archive A.jsa, before it uses OldX, it can dynamically load an alternative version of Sub that's not a subtype of Super. As a result, when the application tries to use OldX later, it will get a VerifyError because the verification constraints of X have been violated.

IMPACT TO LEYDEN:

In Leyden, we plan to archive heap objects that are instances of application classes. Many of today's applications still use "old" classes (usually due to usage of older class libraries). If we happen to archive an object instance of X, but X becomes unverifiable due to verification constraint violations, the archived heap objects may become unusable.

PROPOSAL:

If the class OldX is loaded by the boot, platform, or app class loader, *and* AOT class linking is enabled for the AOT cache:
 
- In the AOT cache assembly phase, we record all the classes that are resolved by the old verifier during the verification of OldX. This can be done by intercepting JVM_FindClassFromClass(). Such classes are called the "verification dependencies" of OldX.

- Before writing OldX into the AOT cache, we check if any of its verification dependency classes are excluded. If so, OldX is also excluded from the AOT cache. Otherwise, OldX is stored in the AOT cache in the "linked" state.

- During the production run, due to the AOT class linking optimization, OldX and all of its verification dependency classes are unconditionally loaded during VM bootstrap. It's impossible for the application to replace any of the verification dependency classes. This means that the verification result of OldX computed in the assembly phase will remain valid in the production run.