[concurrency-interest] Re ference Collections
stanimir at riflexo.com
Thu Jan 5 06:13:42 EST 2012
I am not sure how differently weak/soft references are handled by the GC.
Yet creating tons of them might have adverse effects, esp if the real key is
GC'd before the wrapping references. That will create a lot of work for the
Ideally you may wish to skip wrapping keys on get() but in that case the
default impl. of CHM not suffice. A possible mitigation of the problem via a
non-reference class (just extending Object) that has equals/hashCode the
same as the wrapping references.
My understanding of the ReferenceMap would be that it should not affect
normal operation if it's not expunged at all besides creating leaks. If
that's true you may wish just to check System.currentTimeMillis and expunge
once a (few) seconds.
Few other musings:
* ReferenceQueue is actually a stack but still called queue, indeed it's
filled from another stack (ReferenceHandler) but still it acts as stack.
Unfortunately, it doesn't have have drain() method that looks like a good
optimization acquiring the monitor just once and reducing the contention of
the fast path (head!=null). Imo, the code would be better off 1st draining
the queue in temporary collection, reducing the possible contention and then
performing the real expunge, increasing the odds to coarsen the monitor. The
queue also keeps internal size that's not published anywhere.
* SoftReferences are sort of hit and miss - very cheap to make memory caches
and quite unreliable under load or when keeping references to large native
objects like direct ByteBuffer or java.util.zip.Deflater. There is no
contract when their reclamation comes so the application may show quite
different behavior but just chagning the garbage collector.
Peter Firmstone-3 wrote:
> CAS for single or few threads and less memory consumption, the dedicated
> cleanup thread for scalability.
> Reference Collection's can be widely applied to any java collection
> type, my current concern is scalability for large collections (including
> concurrent maps) which I have no way of testing.
> In the implementation, the only mutable state is in ReferenceQueue, the
> underlying collection and Reference, everything else is final or uses
> method variables. Dummy References, used for reads, are created and
> discarded and die young, so never enter main memory. Hopefully the
> majority of state should be in cache during execution. My main concern
> is the current design employed a ReentrantLock.tryLock() call to hand
> maintenance to one of the calling threads, I was worried that this would
> limit scalability. The feedback so far is yes (info much appreciated).
> The symptom seen by calling threads is occasional null return values in
> iterators. This isn't a problem if the caller expects a null. I'd
> imagine the cleanup thread will catch up. ReferenceComparator
> encapsulates existing Comparator's and guards against null. This could
> be a problem for existing code if the collection is used as a drop in
View this message in context: http://old.nabble.com/Reference-Collections-tp33078668p33084757.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
More information about the Concurrency-interest