[concurrency-interest] ForkJoin updates

Doug Lea dl at cs.oswego.edu
Fri Feb 3 13:28:09 EST 2012

On 02/03/12 11:29, Jason Mehrens wrote:
> Hi Doug,
> Would unconditionally marking the ForkJoinTask as ineligible for biased locking,
> as described in http://blogs.oracle.com/dave/entry/biased_locking_in_hotspot,
> offer the same performance improvement as system wide disabling of biased locking?

I don't plan to do this, but resolving this in a better way is
among the  "other" remaining changes for this round I mentioned.

First, mostly as an aside, biased locking rarely improves, and
often reduces, performance on most Intel i7+ processors. (At
least on programs I run, for which bias code that averages more
than 10 cycles to avoid a sub-10 cycle uncontended CAS loses.)
Probably it should be disabled on them by default.

The main problem with biased locking for FJ is the current
revocation policy. Often, a task either signalling or being
signalled about a join gets stuck stalled until a GC pass
unbiases the lock. The unluckiest of these cases cascade into
stalls involving many threads/cores, which are the main cause
of the unwanted positive feedback loops I've mentioned that
force compensation to be overly conservative.

I'd rather not use a workaround (hashCode) that happens
to work only on (some versions of) hotspot. But there are
other means of somewhat more portably avoiding
biasing, thin-locks, etc. None are perfect but I plan on
settling on one of them soon.


More information about the Concurrency-interest mailing list