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:
I have another idea that might be worth looking into. One problem with
security manager performance is that many times a class will perform
privileged actions in the static initializer block. This is because
static class initialization runs with whatever security context is
active when that class happens to be initialized - it's essentially
random as far as most developers are concerned, and even the experts
cannot always correctly predict how initialization happens (see: last
several years of java.util.logging class init debacle).
This causes performance (and usability) problems because:
• Static init blocks can, for most practical purposes, never rely on
their caller, so they must always perform privileged actions within
doPrivileged
• This also results in another class to load and initialize
• Often, there is more than one data item needed from the privileged
block, requiring either multiple doPrivileged calls (slow) or using
hackery like returning an Object[] array out of the block
I would suggest that one or more of the following be done to mitigate
this problem:
• Always have static initialization blocks be privileged (this does
require users to be cognizant of this fact when writing static blocks)
• Allow static initialization blocks to partake in the aforementioned
annotation-driven privileged method idea
• Introduce a new permission checking mechanism which examines only a
specific relevant caller's protection domain (perhaps determined by
filter expression, possibly using the stack examination scheme that
Mandy Chung has been working on)
• Introduce a programmatic "elevation" mechanism that increases the
privileges of the currently executing method for the remainder of its
execution without requiring a call-in to doPrivileged or instantiation
of a privileged action object
--
- DML
