There doesn't seem to be much interest in adopting an external policy provider, so I'll explain how to achieve a significant performance improvement, in case someone's interested in improving performance of the default jvm policy provider.

  1. Thread confine and immediately discard PermissionCollection
     objects, do not cache them as is done presently.
  2. We created an object representation of grant statements from
     policy files in memory, it is immutable and replaced during policy
     refresh calls, it is also non blocking and highly scalable.
  3. During a policy implies call, collect all grant statements that
     imply a ProtectionDomain from an implies call.  Take Permission
     objects from the grant statements and add them to
     PermissionCollection and Permissions (a heterogenous collection of
     PermissionCollection objects, itself an instance of
     PermissionCollection).  Determine the result of the implies call
     and discard the Permissions, do not cache or share them with other
     threads.
  4. Sort Permission objects before adding them to ProtectionDomain, to
     minimise unnecessary DNS calls from SocketPermission etc.
  5. Do not add Permissions to a ProtectionDomain that delegates to the
     Policy provider, or Permissions may be checked twice.
  6. Only add Permissions to ProtectionDomain's when they have
     AllPermissions or when it does not delegate to a Policy provider.

PermissionCollection was designed to be threadsafe, I think this was a mistake (hindsight is 20:20), similar to HashTable and Vector, PermissionCollection instances should be thread confined (uncontended synchronization is fast). Permissions has a race condition that prevents UnresolvedPermission's from resolving on occassion too, thread confinement fixes that too.

Regards,

Peter.

On 19/07/2014 6:31 PM, Peter Firmstone wrote:
Thought I might provide a comparison using our random stress test on a 4 way sony vaio, JDK7 Windows 7 amd64:

Note that using sun.security.provider.PolicyFile doubles the duration of the stress test and it consumes 73% of CPU.

In comparison org.apache.river.api.security.ConcurrentPolicyFile uses 0% CPU and the test completes in half the time, with our policy provider we run at raw socket speed.

See attached.

Regards,

Peter.

Reply via email to