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

[Andrig Miller]

The SPECjEnterprise2010 benchmark requires EE 5, so it will not require a security manager.

I'm all for making sure we make it run as efficient as possible, I just don't want to go backwards, and have to rework something down the road.

So, perhaps we should do a SPECjEnterprise2010 run with this change, and without it, and see what the impact seems to be.

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 8:03:40 AM
> Subject: Re: [jboss-as7-dev] About the getSecurityManager() optimization
> 
> 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 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
> >>
> 
> 
> --
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>