9:03 a.m.
I'm definitely interested in getting some real idea as to the runtime
cost of (a) these checks and (b) running under a secmgr. I know for
sure that (b) is nowhere near as great as I expected (though obviously
not free), due in part possibly to the Modules<->SM integration code and
Policy implementation which (I believe) enables certain fast-path
optimizations within AccessController.
I would also couple that outstanding question with my observation, based
on analyzing (and refactoring) all 300+ privileged blocks in the AS
codebase, that none of them are in request fast paths, apart from the
privileged action interceptors I just wrote (which would only be used to
replace the (theoretically) similarly expensive existing security
interceptors).
Overall I'd want to see hard numbers before I worry too much. As far as
SPECj goes, if it requires an EE-certified server configuration then it
may have to run under a security manager no matter what (this
configuration is required to be supported by EE 7 and might in turn be
required for apples-to-apples comparison with other servers). In this
case it's no longer a question of "do we do this optimization" and more
a question of "how can we make this as efficient as possible", which IMO
we should be asking anyway.
Based on the analysis I've done so far, I suspect the greater cost of
these doPrivileged calls is one-time class init and general GC load,
both of which I've mitigated really a lot in my security-utils patch
which removed hundreds of anonymous inner classes and replaced a bunch
of action objects with a handful of singletons. And I don't think we're
at the end of what we can do to improve things on this front either.
On 03/04/2013 08:49 AM, Andrig Miller wrote:
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(a)redhat.com>
> To: "JBoss AS7 Development" <jboss-as7-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
--
- DML