RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

David Holmes 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-hardened-hotspot
>                            enable hardenening 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]
> 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/
> /Erik

More information about the hotspot-dev mailing list