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

Remi Forax forax at univ-mlv.fr
Thu Jul 23 20:12:46 EDT 2015


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.

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



More information about the Concurrency-interest mailing list