JEP Review Request: Improve Security Manager Performance

[David M. Lloyd]

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