JDK-8199807 : AppCDS performs overly restrictive path matching check
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9,10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-03-19
  • Updated: 2024-11-05
  • Resolved: 2018-05-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11 b15Fixed
Related Reports
Duplicate :  
JDK-8202935 - Create test case for relocated JDK
Relates :  
JDK-8202854 - Hybrid archiving
Description
In JDK 11 (and all prior versions), the path matching check performed by AppCDS is overly restrictive, which invalidates a previously generated archive unnecessarily in certain cases.

Following is one use case that is currently prohibited by the overly restrictive path matching check:

1. Dump the shared archive with -Xshare:dump using a specific JDK 11 image
2. Copy the JDK image and generated archive to another device (with different path) or another location
3. Run with -Xshare:on or -Xshare:auto using the same JDK image and archive

The shared archive generated by step 1 can not be used by step 3. With -Xshare:on, the following error is reported:

An error has occurred while processing the shared archive file.
shared class paths mismatch (hint: enable -Xlog:class+path=info to diagnose the failure)
Error occurred during initialization of VM
Unable to use shared archive.

NOTE: The check is only done when -XX:+UseAppCDS is enabled, and not with the basic CDS.
Comments
URL: http://hg.openjdk.java.net/jdk/jdk/rev/83d8b3a25f25 User: jiangli Date: 2018-05-21 19:16:26 +0000
21-05-2018
Thanks Ioi for write a unit test for moving JDK. MoveJDKTest.java is attached.
10-05-2018
The path (boot class path) matching check is done by SharedPathsMiscInfo::check(). Just as a background information, the purpose of the check is to make sure the runtime boot class path is compatible with the dump time: * any existing path entry is the same as dump time * ordering of the path entries is the same as dump time The matching check is done by os::file_name_strcmp(), which essentially is a strcmp(). To address the over-restrictive issue, the check can be relaxed to: 1. verify the first entry is the runtime image (this is guaranteed by ClassLoader::setup_boot_search_path()) 2. verify the compatibility of the remaining entries on the runtime boot class path using os::file_name_strcmp()
01-05-2018