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

David Holmes davidcholmes at aapt.net.au
Thu Jul 23 20:42:18 EDT 2015


Hi Remi,

Remi Forax writes:
> Hi Doug,
> I've again try to understand how the Flow API can be safe and i still do
> not understand.
>
> Let suppose i want to use the OneShotPublisher with the SampleSubscriber
> described in the overview of the class Flow.
> If you take a look to the fields of the class SampleSubscriber:
> - count is written in onSubscribe which is called by the thread that
> call subscribe() but read in onNext() which is called by a thread of the
> executor service.
> - subscription has the same issue, it is initialized by onSubscribe()
> and read by onNext().
> Maybe it's working because ExecutorService.submit() works like
> Thread.start() but as far as i know, the javadoc of sumit() doesn't
> specify that.

Memory Consistency Properties

"Actions in a thread prior to the submission of a Runnable to an Executor
happen-before its execution begins. Similarly for Callables submitted to an
ExecutorService."

http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summar
y.html

Cheers,
David
-----

> Moreover, the API expose an issue that are not visible in the current
> snippets of code,
> onError() can be called either by the thread that have called
> subscribe() and the thread that call onNext(), so basically, onError()
> only works if the code of onError() has no side effect, so
> ex.printStackTrace is fine but anything but logging is not.
>
> I'm sure i'm wrong and there is something subtle that my poor mind
> doesn't understand.
>
> Rémi
>
> On 07/23/2015 04:23 PM, Doug Lea wrote:
> > 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
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list