On 04/25/2014 02:35 PM, Sean Mullan wrote:
On 04/25/2014 10:54 AM, David M. Lloyd wrote:
On 04/25/2014 09:36 AM, Sean Mullan wrote:
Please review a draft of a proposed research JEP to improve the
performance of the Security Manager:
http://cr.openjdk.java.net/~mullan/jeps/Improve-Security-Manager-Performance.00
I am particularly interested in any experience you have measuring or
profiling the performance of your code when run with a Security Manager,
and any potential ideas for optimizations that you may have.
Great! Security manager performance is a constant source of difficulty
for us.
Some optimization ideas I've had in the past:
- Add a ParametricPrivileged*Action<T, U> which accepts a single
parameter, with corresponding doPrivileged()-style methods which accept
a parameter of the same type. This can in many cases mitigate the need
to construct new PrivilegedActions, encouraging reuse instead.
Can you give an example of how this works so I can understand it better?
Sure, basically the interfaces look like this:
public interface ParametricPrivilegedAction<T, P> {
T run(P parameter);
}
public interface ParametricPrivilegedExceptionAction<T, P> {
T run(P parameter) throws PrivilegedActionException;
}
then we have these new methods on AccessController:
public static <T> T doPrivileged(P parameter,
ParametricPrivilegedAction<T, P> action);
public static <T> T doPrivileged(P parameter,
ParametricPrivilegedExceptionAction<T, P> action) throws
PrivilegedActionException;
...with the other additional variants on AccessController (i.e.
accepting an ACC, an ACC + a permission set, *WithCombiner variants).
Then the same action object can be reused, as long as there is a single
object parameter (a fairly common case by my experience).
- Use annotations to designate privileged methods (perhaps in
combination with a requirement that the annotated method be
package-private or private).
I agree that sounds useful, but how does it improve performance?
It improves performance by completely eliminating the need to construct
privileged actions for most use cases, and also by removing bumps to
exception handling. Privileged actions which are methods (particularly
private or static methods) can be invoked with the most minimal overhead
possible, regardless of the number of parameters the action requires.
The value of simplifying the programming model is also substantial I
think, though maybe not directly performance benefiting.
The main expense points we've observed in the past mainly revolve around
the actual permission check (chiefly the compilation of the ACC) and
doPrivileged itself though, so in terms of simply optimizing code, those
two areas seem like the best place to start; I think I could probably
get more detailed information about this, time permitting.
I agree. The permission check is expensive, although doPrivileged is
also an area that we would like to improve because it impacts code
regardless if they are running with a Security Manager.
Relatedly, it would also be nice if there were some way to simplify or
improve the JAAS Subject association mechanism, which also relies on the
ACC, causing a substantial enough performance cost that (AFAICT) no
major Java EE application server actually prefers this mechanism.
Yes, this one I already know about and hope to improve and test as part
of this JEP.
--
- DML
