[NOTE: this feature has been implemented in Leyden repo and should be upstreamed to mainline]

This is a new proposal for supporting the verification of old classes in CDS (see JDK-8309074 for a discussion why old classes are not currently archived in the "verified" state).

BACKGROUND:

Currently, old classes (InstanceKlass::major_version() < 50) are be archived in 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 X, Super, and Sub:

    class X {
        Super get() {
            return new Sub();
       }
    }

During the verification of X, 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 X.

When the application runs with the archive A.jsa, before it uses X, 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 X later, it will receive 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:

For the leyden-premain branch, we have a -XX:+AOTClassLinking option (see JDK-8315737) that loads all the archived classes during JVM start-up. If this option is enable, it's not possible for the application to load alternative versions of Sub and/or Super that would violate the verification constraints of X.

Therefore, as long as -XX:+AOTClassLinking is enabled, we can archive old classes in the verified state. As a result, there's no need to do additional verification constraints checks at run time, as we know that such checks will always succeed.