JDK-8263968 : CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16,17
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-03-22
  • Updated: 2021-07-08
  • Resolved: 2021-03-24
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 JDK 17
16.0.1Fixed 17 b15Fixed
Related Reports
Relates :  
JDK-8253081 - G1 fails on stale objects in archived module graph in Open Archive regions
Description
with CDS and G1, JCK test api/java_lang/ModuleLayer/Boot.html fails in JDK 16:

Testcase "parent" failed with message: Expected same as : "", was given: ""
	at com.sun.tck.lib.Assert.fail(Assert.java:494)
	at com.sun.tck.lib.Assert.assertSame(Assert.java:439)
	at com.sun.tck.lib.Assert.assertSame(Assert.java:426)
	at javasoft.sqe.tests.api.java.lang.ModuleLayer.Boot.parent(Boot.java:108)
Testcase "parent" is based on the following statements: 
 - "Its parent is the empty layer"
 -- from source: "ModuleLayer.boot()"
parent: Failed. Expected same as : "", was given: ""

Bisecting has indicated this started failing since JDK-8253081 integration.

The root cause of the problem is that after unpacking the CDS archive there appear to be two instances of empty layer (another one comes from CDS archive). Because of that there is a mismatch between ModuleLayer.empty() (which returns java/lang/ModuleLayer.EMPTY_LAYER) and ModuleLayer.boot().parents().get(0) (which with CDS returns the CDS instance). The spec says [1] that boot() parent for java.base must return THE empty layer, with a link to empty() method.

One solution is to make  java/lang/ModuleLayer.EMPTY_LAYER a singleton similar to java/lang/module/Configuration.EMPTY_CONFIGURATION and initialize this field from CDS archive if CDS is on.

[1] https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/lang/ModuleLayer.html#boot()
Comments
Yep - working on a 16.0.1 backport now.
26-03-2021
Is it possible to backport the fix to jdk 16.0.1? I can't find the jdk16u schedule on JDK 16u wiki page [1] so it is not clear for me is 16.0.1 still open for backports? If backports to 16.0.1 are possible, what is the right procedure to make a backport? [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK+16u
26-03-2021
Fix request (16u) I would like to backport this to jdk16u to avoid the described problems. Applies cleanly. Tested with JCK and jtreg. Note I have not seen the 16u [1] wiki populated yet with timelines and process guidelines, but I'll assume for now that the backport process should be similar to other releases. [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK+16u
25-03-2021
Changeset: 133a63b4 Author: Aleksei Voitylov <avoitylov@openjdk.org> Committer: Claes Redestad <redestad@openjdk.org> Date: 2021-03-24 16:32:36 +0000 URL: https://git.openjdk.java.net/jdk/commit/133a63b4
24-03-2021
I'm waiting for a 24h timeout for the review process to integrate the fix. I suspect there should be sufficient interest from the community to expedite a critical backport to 16.0.1 and if so, if anyone besides myself can report any successful test results for such a backport. The patch from the review applies cleanly to 16u. That would allow to reduce the possible lead time before requesting the backport.
23-03-2021
ILW = conformance, high, do not use CDS => P2.
22-03-2021
tentative fix being tested attached.
22-03-2021