[jboss-as7-dev] About the getSecurityManager() optimization

We have, in our core code and frameworks, a few chunks of code like this: if (getSecurityManager() == null) { doSomePrivilegedThing(); } else { AccessController.doPrivileged(new PrivilegedThingAction()); } The idea is that doPrivileged and the action GC load is a cost we should not pay if there's no security manager. There is a potential problem here though. It is possible to install a security manager after the server is started. While this may sound like an odd thing to do, we know that at least one third-party library does in fact install a security manager if you don't prevent it from doing so. Furthermore, as we're required to support running under a security manager, we were talking about allowing the subsystem to install a security manager during extension init instead of requiring it to be sent in to the command at boot. The problem is that if you set a security manager during the window between when the presence of a security manager is checked for, and when the privileged action runs, you run the risk of getting a random SecurityException. We'll call this problem "the SM race". It seems to me that we have a few options for supporting running under a security manager: 1) Require it to be specified at boot (pass -secmgr to JBoss Modules in the start script) 2) Let it be set by a security manager subsystem 3) Just run with a security manager at all times Only #1 would allow the above optimization to work, and that's only if nobody else sets a security manager in the meantime. Given that fact, coupled with the observation that running under a security manager does not appear to significantly impact server boot time, I'm wondering if we should get rid of this optimization wherever it appears and just always use doPrivileged. Maybe once we see what kind of time impact -secmgr has on the test suite, we'll know whether this is a reasonable course of action (I would expect the performance impact to be somewhere between running with and without a security manager for the non-SM case, and of course no impact for the SM case). -- - DML