RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled
david.holmes at oracle.com
Sun Jun 10 13:28:26 UTC 2018
On 9/06/2018 7:50 AM, Erik Joelsson wrote:
> On 2018-06-07 17:30, David Holmes wrote:
>> On 8/06/2018 6:11 AM, Erik Joelsson wrote:
>>> I just don't think the extra work is warranted or should be
>>> prioritized at this point. I also cannot think of a combination of
>>> options required for what you are suggesting that wouldn't be
>>> confusing to the user. If someone truly feels like these flags are
>>> forced on them and can't live with them, we or preferably that person
>>> can fix it then. I don't think that's dictatorship. OpenJDK is still
>>> open source and anyone can contribute.
>> I don't see why --enable-hardened-jdk and --enable-hardened-hotspot to
>> add to the right flags would be either complicated or confusing.
> For me the confusion surrounds the difference between
> --enable-hardened-hotspot and --with-jvm-variants=server, hardened and
That's the problem: "hardened" is not a jvm-variant as we have always
defined that! "hardened" is a variation in the same way as product vs
fastdebug versus slow-debug versus (the old) optimized. It is _not_ at
all the same kind of thing as server versus client versus zero etc. The
desire to ship "hardened" in the same image as non-hardened is what is
causing the semantic conflict here. It is like shipping a product and
debug VM together. Sure you can do it, but that's not how we've
categorised things in the past.
I understand the need to make things work this way, so in that sense
selecting jvm-variant=hardened should be seen as specifying
"--enable-hardened-hotspot --enable-hardened-jdk". But
jvm-variant=hardened is really jvm-variant=hardened-server.
> making the user understand it. But sure, it is doable. Here is a new
> webrev with those two options as I interpret them. Here is the help text:
> --enable-hardened-jdk enable hardenening compiler flags for all jdk
> libraries (except the JVM), typically disabling
> speculative cti. [disabled]
> enable hardenening compiler flags for hotspot
> jvm variants), typically disabling
> speculative cti.
> To make hardening of hotspot a runtime choice,
> consider the "hardened" jvm variant instead
> of this
> option. [disabled]
> Note that this changes the default for jdk libraries to not enable
> hardening unless the user requests it.
That's your call. I don't care what the default is as long as the
developer has control over it.
> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
More information about the hotspot-dev