[concurrency-interest] Upcoming j.u.c resyncs
dl at cs.oswego.edu
Fri Sep 24 08:05:57 EDT 2010
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
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
* 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).
More information about the Concurrency-interest