Policy provider comparison

Sean Mullan sean.mullan at oracle.com
Fri Jul 25 14:47:15 UTC 2014


On 07/19/2014 10:06 PM, Peter Firmstone wrote:
> 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.

Did you consider storing the PermissionCollection objects in a 
ConcurrentHashMap (instead of the current Collections.synchronizedMap)?

My jmh benchmark (with 5 threads where each thread has its own 
ProtectionDomain) shows a ~3x increase in throughput of Policy.implies 
with just this change. I plan to try the thread confinement approach next.

--Sean

>    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.
>



More information about the security-dev mailing list