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?
- 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?
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.
Thanks,
Sean
