We have two ways to initialize narrow Klass encoding: either we let the JVM chose base and shift freely, or we dictate base and shift. The former gives the JVM more leeway, e.g. to go with unscaled encoding. The latter, however, is required if we load a CDS archive and that archive contains precomputed narrow Klass IDs.

In the Legacy VM, this can only happen if the archive contains heap objects. In Lilliput, however, the markword carries the nKlass. Therefore, the prototype baked into archived Klass structures carries the nKlass, too.

Therefore, we must always chose the latter initialization when +UseCOH.

If we don't, we may cause errors in rare cases (initialization crashes). Precondition for errors are:

- we generate and run with an archive that had been created using +UseCOH
- we don't use CDS heap archiving (Windows, or did not build with G1 support)
- when reserving the class space, we optimize for zero- or unscaled encoding even though we run with CDS. This is highly CPU-specific; on some platforms, we do that today (eg PPC), on x64, it will be the case once JDK-8323497 is merged