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
