JDK-8252919 : JDK built with --enable-cds=no fails with NoClassDefFoundError: DirectMethodHandle$Holder
  • Type: Bug
  • Component: tools
  • Sub-Component: jlink
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2020-09-08
  • Updated: 2024-11-22
  • Resolved: 2020-09-10
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 16
16 b16Fixed
Related Reports
Relates :  
JDK-8252725 - Refactor jlink GenerateJLIClassesPlugin code
Description
This issue can be reproduced also on Linux x86_64.

Build with '--enable-cds=no'

Run: make run-test TEST=hotspot/jtreg/sanity

Output:

Building target 'run-test' in configuration '/priv/d038402/builds/TEST_BUILDS_NOEA/0/ea_new_jdk_lu0486_64_release'
Test selection 'hotspot/jtreg/sanity', will run:
* jtreg:test/hotspot/jtreg/sanity

Running test 'jtreg:test/hotspot/jtreg/sanity'
Error occurred during initialization of boot layer
java.lang.NoClassDefFoundError: java/lang/invoke/DirectMethodHandle$Holder
Error: Compilation of extra property definition files failed. rc=1
Finished running test 'jtreg:test/hotspot/jtreg/sanity'
Test report is stored in /priv/d038402/builds/TEST_BUILDS_NOEA/0/ea_new_jdk_lu0486_64_release/test-results/jtreg_test_hotspot_jtreg_sanity

==============================
Test summary
==============================
   TEST TOTAL PASS FAIL ERROR
>> jtreg:test/hotspot/jtreg/sanity 1 0 0 1 <<
==============================
TEST FAILURE
Comments
Changeset: 44a74dac Author: Mandy Chung <mchung@openjdk.org> Date: 2020-09-10 16:04:58 +0000 URL: https://git.openjdk.java.net/jdk/commit/44a74dac
10-09-2020
A simple fix is to retain the original Holder classes if no trace file is supplied. --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java @@ -141,6 +141,9 @@ public final class GenerateJLIClassesPlugin implements Plugin { initialize(in); // Copy all but DMH_ENTRY to out in.transformAndCopy(entry -> { + // No trace file given. Copy all entries. + if (traceFileStream == null) return entry; + // filter out placeholder entries String path = entry.path(); if (path.equals(DIRECT_METHOD_HOLDER_ENTRY) ||
09-09-2020
I can reproduce this with an image that is created with jlink with --generate-jli-classes option but default_jli_trace.txt file does not exist. Before JDK-8252725, the placeholder classes are regenerated as `JavaLangInvokeAccess::generateXXXHolderClassesBytes` methods are invoked unconditionally (i.e. when default_jli_trace.txt does not exist). $ jdk/bin/javac -J-Xlog:init=debug Error occurred during initialization of boot layer java.lang.NoClassDefFoundError: java/lang/invoke/DirectMethodHandle$Holder at java.base/java.lang.invoke.DirectMethodHandle.<clinit>(DirectMethodHandle.java:951) at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:3779) at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:3735) at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:3977) at java.base/java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:3925) at java.base/java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:614) at java.base/jdk.internal.module.DefaultRoots.compute(DefaultRoots.java:52) at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:304) at java.base/java.lang.System.initPhase2(System.java:2056)
09-09-2020
This seems to be caused by JDK-8252725
09-09-2020
You have to disable cds when configuring (see description): '--enable-cds=no' $ ./images/jdk/bin/java -Xshare:on -version Shared spaces are not supported in this VM Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
09-09-2020
Have run a build on no-cds on linux-x86_64 ,could not repeat the failure(with the patch): linux-x86_64: Linux (XXXX) 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux by running make run-test TEST=hotspot/jtreg/sanity: ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/sanity 1 1 0 0 ============================== TEST SUCCESS The binary is No-CDS: java -Xshare:on -version An error has occurred while processing the shared archive file. Specified shared archive not found (/home//jdk/build/linux-x86_64-server-slowdebug/images/jdk/lib/server/classes.jsa). Error occurred during initialization of VM Unable to use shared archive. Remove the patch, build non-cds, diff the default_jli_trace.txt for non-cds(no patch) vs cds(patch): 43a44 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LL (generated) 61a63 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLL (generated) 64a67 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLL (generated) 70a74 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLL (generated) 73a78 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LJ (generated) 77a83 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLLL (generated) 81a88 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLLLL (generated) 84a92 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLLLLL (generated) 87a96 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLLLLLL (generated) 90a100 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLLLLLLL (generated) 93a104 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLLLLLLLL (generated) 98a110 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLLLLLLLLL (generated) 101a114 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_LLLLLLLLLLLLL (generated) 134a148 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_D (generated) 139a154 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_DL (generated) 144a160 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_I (generated) 149a166 > [SPECIES_RESOLVE] java.lang.invoke.BoundMethodHandle$Species_IL (generated) There are more generated Species LFs with BMH, the failure is with DMH, so looks not related.
08-09-2020
Would it not be easier to analyze the issue with the test 'hotspot/jtreg/sanity'? (see above)
08-09-2020
ILW=HLM=P3
08-09-2020
I've got this in my environment: LANG=en_US.UTF-8. $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=
08-09-2020
Just to add to Mandy's comment, I think it would be useful to know if there are any locale or charset issues at play.
08-09-2020
It is also observed on Linux x86_64. Pls see comment above.
08-09-2020
This is strange. This failure is only observed on AIX. Do you see any difference between $BUILD_OUTPUT/support/link_opt/default_jli_trace.txt with and without JDK-8252725? Another thing to check is to instrument GenerateJLIClassesHelper::generateHolderClasses to dump the class names of the spinned classes (i.e. the key of the returned map)? and compared to the classes spinned GenerateJLIClassesPlugin without this patch. That'd help to nail down any holder classes are not generated due to JDK-8252725 if any.
08-09-2020
If I build without CDS (--enable-cds=no) then I get these errors also on Linux x86_64 when running jtreg tests. $ make run-test TEST=hotspot/jtreg/sanity Building target 'run-test' in configuration '/priv/d038402/builds/TEST_BUILDS_NOEA/0/ea_new_jdk_lu0486_64_release' Test selection 'hotspot/jtreg/sanity', will run: * jtreg:test/hotspot/jtreg/sanity Running test 'jtreg:test/hotspot/jtreg/sanity' Error occurred during initialization of boot layer java.lang.NoClassDefFoundError: java/lang/invoke/DirectMethodHandle$Holder Error: Compilation of extra property definition files failed. rc=1 Finished running test 'jtreg:test/hotspot/jtreg/sanity' Test report is stored in /priv/d038402/builds/TEST_BUILDS_NOEA/0/ea_new_jdk_lu0486_64_release/test-results/jtreg_test_hotspot_jtreg_sanity ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/sanity 1 0 0 1 << ============================== TEST FAILURE
08-09-2020