RFR: 8293980: Resolve CONSTANT_FieldRef at CDS dump time [v8]

[Ioi Lam]

> ### Overview
> 
> This PR archives `CONSTANT_FieldRef` entries in the _resolved_ state when it's safe to do so.
> 
> I.e., when a `CONSTANT_FieldRef` constant pool entry in class `A` refers to a *non-static* field `B.F`, 
> - `B` is the same class as `A`; or
> - `B` is a supertype of `A`; or
> - `B` is one of the [vmClasses](https://github.com/openjdk/jdk/blob/3d4185a9ce482cc655a4c67f39cb2682b02ae4fe/src/hotspot/share/classfile/vmClasses.hpp), and `A` is loaded by the boot class loader.
> 
> Under these conditions, it's guaranteed that whenever `A` tries to use this entry at runtime, `B` is guaranteed to have already been resolved in A's system dictionary, to the same value as resolved during dump time.
> 
> Therefore, we can safely archive the `ResolvedFieldEntry` in class `A` that refers to `B.F`.
> 
> (Note that we do not archive the `CONSTANT_FieldRef` entries for static fields, as the resolution of such entries can lead to class initialization at runtime. We plan to handle them in a future RFE.)
> 
> ### Static CDS Archive
> 
> This feature is implemented in three steps for static CDS archive dump:
> 
> 1. At the end of the training run, `ClassListWriter` iterates over all loaded classes and writes the indices of their resolved `Class` and `FieldRef` constant pool entries into the classlist file, with the `@cp` prefix. E.g., the following means that the constant pool entries at indices 2, 19 and 106 were resolved during the training run:
> 
> @cp java/util/Objects 2 19 106
> 
> 2. When creating the static CDS archive from the classlist file, `ClassListParser` processes the `@cp` entries and resolves all the indicated entries. 
>  
> 3. Inside the `ArchiveBuilder::make_klasses_shareable()` function,  we iterate over all entries in all archived `ConstantPools`. When we see a  _resolved_ entry that does not  satisfy the safety requirements as stated in _Overview_, we revert it back to the unresolved state.
> 
> ### Dynamic CDS Archive
> 
> When dumping the dynamic CDS archive, `ClassListWriter` and `ClassListParser` are not used, so steps 1 and 2 are skipped. We only perform step 3 when the archive is being written.
> 
> ### Limitations
> 
> - For safety, we limit this optimization to only classes loaded by the boot, platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during the training run. We don't speculatively resolve other entries, as doing so may cause C2 to unnecessarily generate code for paths that are never taken by the app...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed failures with -Xcomp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19355/files
  - new: https://git.openjdk.org/jdk/pull/19355/files/d0b37dc2..ee7a2960

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19355&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19355&range=06-07

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19355/head:pull/19355

PR: https://git.openjdk.org/jdk/pull/19355