JDK-8188109 : JVM should print a warning message that -Xshare:on may cause VM to abort start-up
- Type: Enhancement
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 9,10
- Priority: P3
- Status: Resolved
- Resolution: Withdrawn
- Submitted: 2017-09-28
- Updated: 2019-06-20
- Resolved: 2018-05-31
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.
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 |
|---|
11Resolved  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
CDS maps the archive file at a fixed address. On some platforms, especially Windows and 32-bit Linux, there's a chance that, with address space layout randomization, the CDS address may have been occupied by a system DLL before the JVM starts. In this case, CDS mapping will fail. -Xshare:auto continue to execute (with CDS enabled), but -Xshare:on will exit the JVM. The mapping failure is much more rare on 64-bit Linux, but nevertheless, in a production environment, you should use -Xshare:auto and not -Xshare:on. This behavior -Xshare:on option is very much a legacy feature that was not well designed. The JVM should at least print out a warning message. Or better, make -Xshare:on behave the same as -Xshare:auto (but a lot of our tests depend on the -Xshare:on failure mode), so doing that would require more work.
Comments
|