This is forked from [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) and filed as a general issue for archived boxed Integer cache when it's recreated at runtime. In short, current code drops the entire primitive cache when the CDS archived version of the cache is too short. This poses a problem with code that uses CDS archived cache instances, since the boxed equality would break when comparing the CDS-archived value and the IntegerCache value recreated at runtime.
Ioi suggested a fix here: https://github.com/openjdk/jdk/pull/21672#issuecomment-2434359711. I separately arrived to the same idea. This PR implements it. `IntegerCache` gets the special treatment, because it is the only cache that can be tuned. Other caches just prevent the use of bad archived cache (which I think should realistically never happen) without re-creating it. Unfortunately, I was unable to create a standalone CDS test for this: I somehow need to be able to put my own archived `Integer` instance into the archive, and I don't clearly see how. I tested this patch with original reproducer from [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) -- and it starts to pass. I don't think we would be able to convert that reproducer into a unit test, since [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) itself would make the reproducer ineffective. Additional testing: - [x] macos-aarch64-server-fastdebug, [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) reproducer now passes - [x] linux-aarch64-server-fastdebug, `all` ------------- Commit messages: - Exception messages - Fix Changes: https://git.openjdk.org/jdk/pull/21737/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21737&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343019 Stats: 22 lines in 5 files changed: 17 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21737/head:pull/21737 PR: https://git.openjdk.org/jdk/pull/21737
