-Xshare:dump with default classlist fails on static JDK:
$ bin/java -Xshare:dump
Error occurred during initialization of VM
Loading classlist /<snip>/build/linux-x86_64-server-slowdebug/images/lib/classlist failed: No such file or directory
Many CDS jtreg tests do -Xshare:dump using the default classlist and fail on static JDK. I noticed the failures recently when testing on mainline. The hermetic Java prototype works on top of other changes which masks the issue, hence leyden/hermetic-java-runtime has not been fixed for this specific issue.
MetaspaceShared::get_default_classlist resolves the default classlist path using os::jvm_path returned path. On regular JDK, os::jvm_path gives the path to libjvm. MetaspaceShared::get_default_classlist removes the last two directory components (e.g. '<variant>/libjvm.so') from the path, then adds 'lib/classlist' to the path. There is also some subtle handling of adding '/lib' component optionally.
On static JDK, os::jvm_path returns the path to the 'bin/java' launcher executable. Due to the directory structure difference, the assumption is MetaspaceShared::get_default_classlist is no longer true, hence resolves incorrect path.
I think Arguments::get_java_home should be used when resolving the default classlist path. It avoids complications of walking up the directory from libjvm and subtle handling for '/lib' dir.
$ bin/java -Xshare:dump
Error occurred during initialization of VM
Loading classlist /<snip>/build/linux-x86_64-server-slowdebug/images/lib/classlist failed: No such file or directory
Many CDS jtreg tests do -Xshare:dump using the default classlist and fail on static JDK. I noticed the failures recently when testing on mainline. The hermetic Java prototype works on top of other changes which masks the issue, hence leyden/hermetic-java-runtime has not been fixed for this specific issue.
MetaspaceShared::get_default_classlist resolves the default classlist path using os::jvm_path returned path. On regular JDK, os::jvm_path gives the path to libjvm. MetaspaceShared::get_default_classlist removes the last two directory components (e.g. '<variant>/libjvm.so') from the path, then adds 'lib/classlist' to the path. There is also some subtle handling of adding '/lib' component optionally.
On static JDK, os::jvm_path returns the path to the 'bin/java' launcher executable. Due to the directory structure difference, the assumption is MetaspaceShared::get_default_classlist is no longer true, hence resolves incorrect path.
I think Arguments::get_java_home should be used when resolving the default classlist path. It avoids complications of walking up the directory from libjvm and subtle handling for '/lib' dir.
- relates to
-
JDK-8303796 Optionally build fully statically linked JDK image
-
- Open
-
- links to
-
Review(master)
openjdk/jdk/24000