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

[Andrig Miller]

This concerns me where our SPECjEnterprise2010 benchmarking efforts are concerned.

At this point, we cannot afford anything that could degrade throughput and/or increase CPU utilization.

Andy

----- Original Message -----
> From: "David M. Lloyd" <david.lloyd at redhat.com>
> To: "JBoss AS7 Development" <jboss-as7-dev at lists.jboss.org>
> Sent: Monday, March 4, 2013 7:36:58 AM
> Subject: [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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>