Performance v's scalibility

[Peter <ji...@zeus.net.au>]

Just had some feedback about reference collections from Doug's concurrency interest mail list.

Reference collections are utility classes for using various weak or soft references in any implementing standard java framework collection interfaces.

Anyway these collection utils need to perform routine maintenance on the underlying collection to remove dead references.

I originally used calling threads to perform maintenance, but feedback from the list suggested this would only scale to 8 cpu's 

Not much chop considering Cliff Click's NonBlockingHashMap scales linearly to 768 cpu's!

Based on the feedback recieved, I've implemented a global scheculed executor that performs background maintenance on behalf of all reference collections.  Each collection gets it's own ReferenceQueue for maintenance (Map's get up to 2).

This moves maintenance completely out of the way of calling threads, so the underlying collection can achieve near native performance.

This learning also means the new DynamicPolicyProvider needs to loose it's cache, slower single threaded performance, much higher scalability.  Even more important now considering the new SecurityManager divides the AccessControlContext into separate tasks for each ProtectionDomain, increasing parallelism (only when there are 4 or more PD's on the stack).

This also means I'll have to abandon new code like ConcurrentPermissions, MultiReadPermissionCollection and DynamicPermissions (all PermissionCollection implementations).

I'll need a new policy interface to get at PermissionGrants from underlying Policy implementations.  (PermissionGrants are immutable unlike Permissions -not to be confused with Permission, and ConcurrentPermissions )

Developers will have to rely on ProtectionDomain's static Permissions for the AllPermission optimisation that avoids calling the policy, so it will be important for all Classloaders to call Policy.getPermissions(CodeSource cs).

One advantage is this removes some complexity, for easier long term maintenance, another is even with the cpu concurrency trend, I won't have to touch it again for a very long time.

Cheers,

Peter.