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

[Magnus Ihse Bursie]

On 2018-06-10 15:28, David Holmes wrote:
> 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 disagree. The "no-speculative-cti" is a perfectly fine JVM feature, 
which can be applied to any JVM variant. It is not a JVM feature as a 
separate software component (like cmsgc or compiler1) that could be left 
in or kept out and that affects the functionality of hotspot. Instead, 
it is a JVM feature very much like the existing link-time-opt, in that 
it affects all aspects of the JVM; not the functionality, but the 
performance (and security).

The way we bundle a certain set of JVM features as a named JVM variant 
has always been a bit, well, semantically odd, but it has served us okay 
in the past and serve us just as well for this fix.

>
> 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.
Yes, jvm-variant=hardened is actually hardned-server. Despite the longer 
name, it might be more clear to use that name. It ties in into a bit 
into Erik's original "altserver" proposal.

I think the reason just "hardened" sounds like a reasonable alternative 
to the more proper but longer "hardened-server" is due to how "server" 
has become the mainstream variant, even for clients, and "client" feels 
like it's being put on death row. Nobody really believes that it will 
survive in the long term, and nowadays Oracle don't even build it 
anymore (we stopped doing that when we stopped doing 32-bit builds). So 
"server" is increasingly incorrectly named, and should really just be 
considered a legacy name for what should perhaps be "default" or so.

/Magnus

>
>> 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.
>
> Thanks,
> David
>
>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/
>>
>> /Erik