[concurrency-interest] Critical fix in jsr166y for Scala 2.10.2

Philipp Haller hallerp at gmail.com
Wed May 1 04:07:55 EDT 2013

Hi all,

Scala's standard library ships with a fork of jsr166y to provide a high-performance thread pool on Java6.

We've recently discovered a performance/scalability bug in our fork which lead to underutilized worker threads (see https://issues.scala-lang.org/browse/SI-7438).

The most recent versions of jsr166y and jsr166e do not suffer from this bug.

A workaround using the revision of jsr166y shipped in Scala is not to use `fork` in our global "execution context". However, this seems like a drastic measure, since we would loose the benefit of submitting to local work queues if possible. (In the past we have seen tangible scalability improvements in actor-based code.)

Since this is a critical issue, we're planning to provide a fix in Scala 2.10.2. Our questions are:
- Given that Scala 2.10.2 will be binary compatible with Scala 2.10.1, is it safe to update to the latest revision of jsr166y? In other words, are later revisions of jsr166y binary compatible with earlier revisions?
- Besides the above fix, are there any other observable changes to be expected when updating jsr166y to the latest revision?
- How much performance would we loose by avoiding the use of `fork`? How much scalability?
- Would it make sense to cherry-pick the commit that fixes the issue? (We haven't pinpointed, yet, which commit fixes the issue.)

The jsr166y fork shipped in Scala 2.10.1 is based on revision 1.89 (Apr 9, 2012).

Any advice would be much appreciated.


See you at Scala Days (June 10–12, NYC)!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130501/efd9f4c1/attachment.html>

More information about the Concurrency-interest mailing list