On 2018-09-16 07:05, David Black wrote:
On 14 September 2018 at 13:46, David Lloyd<david.ll...@redhat.com> wrote:
On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan<sean.mul...@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
