[concurrency-interest] ForkJoin updates
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