Policy provider comparison

[Sean Mullan]

Hi Peter,

This list of optimizations looks very useful - thank you for sending 
more details! I am going to spend some time thinking about your 
suggestions in more detail and how they apply to the OpenJDK JavaPolicy 
provider and will get back to you with any further questions ...

--Sean

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