RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

[Claes Redestad]

On 2018-09-16 07:05, David Black wrote:
> On 14 September 2018 at 13:46, David Lloyd<david.lloyd at redhat.com>  wrote:
>> On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan<sean.mullan at oracle.com>  wrote:
>>> This is a SecurityManager related change which warrants some additional
>>> details for its motivation.
>>>
>>> The current System.setSecurityManager() API allows a SecurityManager to
>>> be set at run-time. However, because of this mutability, it incurs a
>>> performance overhead even for applications that never call it and do not
>>> enable a SecurityManager dynamically, which is probably the majority of
>>> applications.
>> What kind of performance overhead?
> Yes, have you done performance tests to determine what the overhead is
> in "standard applications" (the micro-benchmark in
> https://bugs.openjdk.java.net/browse/JDK-8191053  might not be
> reflective of actual application performance differences).
>


You're right that this does not really say much about performance
in a "standard application". The micro in the bug is simply a
verification that constant folding does happen as hypothesized.
It's plausible this can help the JIT optimize and inline more
aggressively, possibly leading to "real" speedups higher up in the
stack on some "real" applications.

The problem, however, is that there's no such thing as a "standard
application" benchmark. Most industry standard benchmarks are
really microbenchmarks in disguise, where the score is determined
by behavior in a limited number of bottlenecks, and the probability
any of these bottlenecks will be affected by any particular
optimization is disturbingly close to zero.

Thus, using "we need to see a real performance difference on
some real benchmark" as a criterion then very quickly becomes a
strong filter against almost all optimizations. Implemented as a
requirement that'd be devastating for the platform.

Instead we've shifted towards treating an improvement in a
targeted microbenchmarks while not causing any regressions
on a wide range of standard benchmars as an accept criterion.

It's not a perfect strategy, but for a complex and performance
critical platform like the OpenJDK I think it's far better than the
alternatives.

/Claes