[concurrency-interest] Reference Collections
nathan.reynolds at oracle.com
Thu Jan 5 11:29:18 EST 2012
One could get around the finalizer if the task keeps a WeakReference to
the ReferenceQueue. If WeakReference.get() returns null, then the task
knows it needs to be cancelled.
Since Referrer objects can't escape, then JIT might be able to get rid
of the object's allocator altogether. I am not sure if current JIT can
do this or if this is an enhancement request waiting to be implemented.
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 1/5/2012 7:07 AM, Peter Firmstone wrote:
> Thinking about it further, the best solution for cleaning reference
> collections is using a static final ScheduledExecutor as part of the
> ReferenceProcessor class.
> That way if all the reference collections in use only require one
> thread, then only one shared thread will be created.
> Each Collection will still get its own ReferenceQueue, it keeps the code
> simple and allows the use of multiple collections to scale, since
> reference queues would be polled only when running as scheduled tasks,
> there's no contention for the ReferenceQueue lock, instead the threads
> increase if the load increases and there a plenty of queues to share
> among the threads.
> A disadvantage is the ReferenceProcessor needs a finalizer to cancel the
> task in the scheduled executor when no longer required.
> Example: ConcurrentMap<AccessControContext,Set<Permission>> checked,
> using weak keys referring to ConcurrentSkipListSet's containing soft
> In this case there would be one ReferenceQueue for the keys and one for
> each of the Set's.
> The path for a calling thread that doesn't add then becomes, create
> referrer object, perform get, remove, contains, then return, discarding
> the referrer. Reference object instances are only created for put,
> putIfAbsent, add, etc - write methods, in this case the ReferenceQueue
> is passed to the Reference constructor, the Reference added to the
> collection then the method returns.
> Do you think this strategy will scale?
> Since Reference Collection's might still be used by client developers
> for single threaded use, I'll probably keep the CAS tryLock() option, in
> case the underlying collection in use doesn't support multi threading.
> Thanks in advance,
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest