New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fork Join's idle hands #7438
Comments
Imported From: https://issues.scala-lang.org/browse/SI-7438?orig=1 |
@soc said: Considering that the JSR166 stuff is all in public domain, starting to use the bundled version of ForkJoin (where available) seems fine (imho). |
@retronym said: |
@retronym said:
|
@viktorklang said (edited on May 1, 2013 6:15:16 AM UTC): I propose the following action plan:
Thoughts? |
@retronym said:
Can you point to particular versions/commits that are critical? I'd like to be sure that they exist in our fork. Would we have the same problem with all JDK7 builds, or just the earlier ones? Sorry if these questions are a bit basic, but I'm not a jsr166 expert, so I need precision in the advice here. |
@phaller said: |
@retronym said: |
@retronym said: |
The version of ForkJoin that we bundle [1] appears to prone to underutilize available cores when using
fork
(as opposed toexecute
). OurExecutionContextImpl
does exactly this as an optimization in nested parallelism.A test case that demonstrates the problem with ForkJoin:
https://gist.github.com/retronym/5420028
The most recent packages of jsr166e and jsr166y do not suffer from this bug.
Suggestion:
fork
. We could restore the this with a system property in case someone really needs that behaviour back.[1]
The text was updated successfully, but these errors were encountered: