On 8 January 2012 11:40, Peter Firmstone <[email protected]> wrote: > Appended is a new java.security.Policy implementation, it fully supports > the existing java policy syntax and accepts alternate PolicyParser's. > > All state is immutable, except for 2 volatile references, referents > replaced, not mutated, when the policy is updated. One referent is an > array containing PermissionGrant's (interface for immutable object > representing a grant statement in a policy), the second a > PermissionCollection containing the Policy Permissions. The array is > never mutated after creation, a reference to the array is copied before > accessing the array or any array methods. > > The policy creates PermissionCollection's on demand for checking, > Permission's are ordered using a PermissionComparator to ensure that for > example, wildcard SocketPermission's are checked first, to avoid > unnecessary DNS lookups. Only the permission being checked and any > UnresolvedPermission's are added to the PermissionCollection, limiting > the size of the objects created. > > In existing policy implementations PermissionCollection's perform > blocking operations. > > Also, after parsing policy files, PermissionGrant implementations avoid > the need to open files or network connections to confirm URL's, eg > CodeSource.implies is not called, but instead reimplemented using URI. > > Will this scale? There but one smell: > > ProtectionDomain uses a synchronized method Policy.getPolicyNoCheck(), > but this only retrieves a reference on 99% of occasions. > > For every permission check, the stack access control context is > retrieved, every ProtectionDomain on the stack must be checked, > ProtectionDomain's must call getPolicyNoCheck() to call > Policy.implies(ProtectionDomain domain, Permission permission). > > To make this worse, I've got a SecurityManager that divides the > ProtectionDomain.implies() calls into tasks and submits them to an > executor (if there are 4 or more PD's in a context). The > SecurityManager is also non blocking, at least it will be when I use the > new ConcurrentHashMap for the checked permission cache (avoids repeated > security checks), for now the cache is implemented using the existing > ConcurrentHashMap, but is mostly read in any case. (P.S. This is the > cache I'm using the Reference Collection's for.) > > How much can this one synchronized method spoil scalability? >
Not much as far as I can see - there's going to be a one off initialisation cost and after that it's a fast path with a single reference check and a return. I can't think of much that's less compute intensive and thus lower contention. I think you'd have to be running some very trivial code that called this method many many times whilst it didn't do much for it to turn up as high cost. > Cheers & thanks in advance, > > Peter. >
