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

[David Lloyd]

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?

> For example, there are lots of "SecurityManager sm =
> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If
> it was known that a SecurityManager could never be set at run-time,
> these checks could be optimized using constant-folding.

I think they could be optimized using constant-folding either way, if
something like SwitchPoint were used instead of a plain field; am I
incorrect in my understanding?  The reason I ask is... (see below)

> There are essentially two main parts to this change:
>
> 1. Deprecation of System.s[etS]ecurityManager()

We (JBoss) use this method to configure some things at run time (like
customizing the Policy) before installing our security manager, so
this would be not so great for us.

-- 
- DML