[concurrency-interest] Upcoming jdk9 j.u.c JEP

Doug Lea dl at cs.oswego.edu
Thu Jul 23 10:23:17 EDT 2015


Thanks to people who have tried out the proposed updates for jdk9
(modest, compared to previous releases) that have been in place since
January -- a few enhancements to CompletableFuture, added class
SubmissionPublisher and its interface-holder class Flow, plus misc
minor updates. If you haven't, try them out from the usual places:

     API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
     jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar (compiled 
using Java8 javac).
     Browsable CVS sources: 
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/

(As usual, the easiest way is to run with -Xbootclasspath/p:jsr166.jar
but this will almost surely change under upcoming jdk9 module support.)

We've been also working to improve async performance more generally
inside implementations. Things seem to be stabilizing without
controversy. (There has been continuing discussion of Flow interfaces
at http://www.reactive-streams.org/ but nothing that has impacted
these APIs.)  So it's time to actually propose them for jdk9 as an
openjdk JEP.  Which I plan to do within a few days. If you have any
comments or concerns, please let me know!

Some notes:

* Reactive-stream users may be disappointed that we do not include any
net/IO-based Flow.Publisher/Subscriber classes, considering that
reactive-streams are mainly motivated by net-based frameworks.  The
reasons for triaging these out are that (1) IO generally falls outside
of java.util.concurrent (2) Most net-based frameworks seem to use
custom data representation etc (e.g., JSON) that are even further out
of scope.  However class SubmissionPublisher can be used as an adaptor
to turn just about any kind of source into a Publisher, so provides a
nearly universal way of constructing a good non-custom Publisher even
from IO-based sources.  (Also notice that SubmissionPublisher can
serve as the basis of other actor-like frameworks, including those
turning off back-pressure by calling
subscription.request(Long.MAX_VALUE) in onSubscribe).

* If you are trying out updates with jdk9 early access,
(https://jdk9.java.net/download/) notice that as of b73 last week,
it by default uses the G1 collector, which is (currently,
but hopefully just transiently) not usually the best choice for
high-throughput concurrency. You probably want to use switches
  -XX:+UseParallelGC -XX:+UseCondCardMark -XX:-UseBiasedLocking

* The implementation updates (some not yet committed) focus on
improvements in async contexts (CompletableFutures,
SubmissionPublishers, plus other older components).  Symmetric async
(where agents may be both producers and consumers) performance is
inherently more variable than other cases. ForkJoinPool in particular
handles now these better. Updates include (1) pool.submit and
task.fork now have identical semantics; (2) "Async" FJP mode is now
probabilistically fair; (3) Spare threads cannot accumulate; and (4)
Ramp-down is faster on large systems.  (In fact, of the oddities under
abuse that Ed Harned enjoys identifying, I think the only remaining
one is that we still take a global lock to fill in stack traces for
cross-thread exceptions, which can slow things to a crawl if you have
tons of them, but is still worthwhile in helping developer track down
most problems.)

* It is likely that some implementations (and possibly even new
classes) will be impacted by VarHandles-related work (mainly by Paul
Sandoz), that replaced the syntactically-nicer but too-problematic
"Enhanced Volatiles" proposal (still the same JEP
http://openjdk.java.net/jeps/193).

-Doug



More information about the Concurrency-interest mailing list