JDK-8202384 : Introduce alternate jvm variant with speculative execution disabled
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 7,8,11
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2018-04-27
  • Updated: 2019-08-05
  • Resolved: 2019-08-05
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.
Other
tbd_majorResolved
Related Reports
Blocks :  
JDK-8207206 - JEP 342: Limit Speculative Execution
Relates :  
JDK-8223042 - Introduce alternate jvm variant with speculative execution disabled for AARCH64
Relates :  
JDK-8203927 - Update version string to identify which VM is being used
Relates :  
JDK-8210670 - Accept double-dash VM-name options at launch time
Description
In order to allow for users not affected by problems with speculative execution to run a JVM at full speed, we need to ship two JVM libraries - one that is compiled with speculative execution enabled, and one that is compiled without. Enabled and disabled in the C++ compiler that builds the JVM, that is.

Experiments were done with JDK 11 on Linux using the new gcc 7.3 with the three flags -mindirect-branch=thunk -mfunction-return=thunk -mindirect-branch-register. When the full JDK is compiled with these flags enabled there is an 18-29% performance regression in startup times. This is because during startup a lot of time is spent in the JVM, which is code compiled by gcc. Throughput benchmarks are largely unaffected since most of their time is spent in JIT compiled code. With a JDK where all native libraries except the JVM are compiled with gcc mitigations it is observed that all the startup regressions are gone.

The recommendation from the Oracle JDK performance team is therefore to offer two versions of the JVM library, one safe and one fast, and to use a single safe version of all other libraries. To achieve this the Java launcher needs to have the ability to allow the user to choose which JVM to run. This is similar to the client/server model that we used to have.

Speculative execution is enabled by default, so a single flag can be used to disable it if desired.


Building the JDK with these options requires gcc 7.3 (linux) or VS 2017 (windows). Other platforms are not affected at this point.
Comments
This is no longer needed as the speculative execution class of bugs can't be satisfactory fixed in software and the JEP is being withdrawn: https://mail.openjdk.java.net/pipermail/vuln-announce/2019-July/000002.html
05-08-2019
New configure flags were scrapped based on review discussion. We just add a new jvm variant that you can request with the already present --with-jvm-variants=. For all libraries except hotspot, the non speculative flags are turned on by default. For hotspot they are only turned on if the jvm feature "no-speculative-cti" is enabled, which it is for the new variant "nonspeculative". The name of the variant is defined in the JEP.
07-09-2018
Adding configure options to give user more control over these flags: --enable-hardened-jdk enable hardening compiler flags for all jdk libraries (except the JVM), typically disabling speculative cti. [disabled] --enable-hardened-hotspot enable hardening compiler flags for hotspot (all jvm variants), typically disabling speculative cti. To make hardening of hotspot a runtime choice, consider the "hardened" jvm variant instead of this option. [disabled]
09-06-2018
Changing names of jvm variant to "hardened" from suggestion in review.
04-06-2018
I've updated my patch to name the jvm-feature "no-speculative-calls" and the new jvm variant which uses the feature by default "altserver" since it's based on server.
01-06-2018
The version string should indicate which configuration is being used. This is a requirement from sustaining as well.
30-05-2018
In the current hotspot version, it prints info about which compilers are present. This used to be the main difference between the jvm variants. You will need someone from hotspot to expand on this.
25-05-2018
There is a lot of work that is dependent on this change. Both the RT and SQE needs this in order to get their processes in order for testing and releasing dual JVM libraries.
16-05-2018
Added affects version 7 and 8 as the work will also need to accommodate those releases.
15-05-2018