[concurrency-interest] Upcoming j.u.c resyncs

The jsr166y/openjdk resyncs mentioned a few weeks ago appear to be complete for openjdk proper, and I think will start appearing in jdk7 binary snapshots soon. For those of you tracking or syncing into other repositories, you might also want to grab updates of tests etc (see the usual links at http://gee.cs.oswego.edu/dl/concurrency-interest/index.html) Sometime soon, we will also check for and resync other j.u.c. updates we have made over the past few years that don't appear in openjdk. Most of these are just small doc clarifications made in response to suggestions on this list, as well as a few performance improvements. But there are also a couple listed below that we'd like reactions about before committing. Plus, now would be a good time to suggest any other minor updates. * PriorityBlockingQueue (which is basically a heap-based priority queue managed under a single lock) employs that lock in "fair" mode, to minimize surprise. However, as most members of this list know, fair-mode locks can be very slow under contention. Even though the specs for the class do not promise fairness, we probably cannot just change this to use non-fair locks without breaking some user code out there that unknowingly relies on it. But we could add new constructors that enable users of this class to decide to use non-fair mode if they encounter performance problems. Since this is an API change, it could only go into Java7 versions. (Aside: A "ConcurrentPriorityQueue", that does not implement BlockingQueue but uses more scalable nonblocking synchronization has been a low-priority candidate for addition for a while. One reason for not adding one sooner is that just using a ConcurrentSkipListSet for such purposes already works pretty well, although has a bigger footprint than a custom priority queue would. * I'm still not very excited about suggested modifications to FutureTask that drop inner Callables/Runnables (to enable prompter GC) upon completion, at the cost of a very small performance hit. The main impetus for this is the lack of efficient cleanup upon cancellation in Java6 ScheduledThreadPoolExecutor. Our current version of ScheduledThreadPoolExecutor does include (optional) faster cleanup, which is a preferable solution because (1) it enables GC of the entire FutureTask object, not just the inner Callable and (2) it has no impact outside of this use case. But unfortunately this required another small API change (adding setRemoveOnCancelPolicy) so wasn't incorporated into Java6 versions. But it is in Java7 versions, and is available for use by others encountering garbage retention problems by getting standalone copies of the class (that will work fine in Java6 VMs). -Doug