[concurrency-interest] Upcoming jdk9 j.u.c JEP
akarnokd at gmail.com
Thu Jul 23 14:55:54 EDT 2015
I've read through the code and javadoc and I have the following comments:
Line 70: the code schedules the exception with executor.execute(() ->
subscriber.onError(ex)); but the subscriber can't cancel this action. For
example, a subscriber calling request(-1) and then cancel() will inevitably
receive the exception. I understand the RS spec allows for such late-coming
events, but since this is an example, it should convey the right practices:
one should always get the future of a scheduled action.
Line 98: the text reads "Subscriber maintains multiple Subscriptions" which
I don't see how would look like and I think the RS spec at least implies
this shouldn't happen.
Line 114: the count variable is set after the request is issued so a
synchronous onNext call will request bufferSize - bufferSize / 2
immediately, having a total of ~1.5 * bufferSize outstanding requests. In
addition, if the generator emits asynchronous onNext events, a stall just
before the count assignment may have the same effect, the onNext may
experience a torn-read of count or onSubscribe and onNext may destroy each
others count value. I suggest assigning count before the initial request.
Line 314: the same issue is present: count is assigned after the request is
Line 325: I think, the subscription needs to be cancelled, otherwise the
Consumer keeps receiving more elements, which may yield undefined behavior
with most subscribers.
Line 361: The consume() method returns a CompletableFuture whose cancel
does nothing and there is no way to cancel the consumption unless the
consumer throws an exception (which also doesn't work now due to 325). I
can see implementing the cancellation is difficult due to the potential
asynchrony involved, so at least the javadoc should mention the problem
Line 416: the text reads "Preliminary release note: Currently, this method
collects all items before executing the stream computation." Correct me if
I'm wrong, but since Stream is pull based, the stream() method would need
to inject concurrency into the flow: the push end fills a queue and the
pull end takes (blockingly) from the queue from some other thread.
Line 69: "to share schedulers" not sure about "schedulers" here, because
the Flow terminology uses Executors otherwise.
Line 222: From experience with RxJava, holding a lock while emitting events
should be avoided, especially when blocking actions are nearby.
Line 230: In RxJava, if the Subject is terminated with an exception, late
Subscribers will receive the exception but here, they just get completed.
Maybe it is worth considering this exception-replaying behavior.
Line 623: getSubscribers() why would anyone be interested in the actual
subscribers? Calling methods on them shouldn't be allowed anyway and I
don't see any other reason to expose them.
2015-07-23 16:23 GMT+02:00 Doug Lea <dl at cs.oswego.edu>:
> 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:
> (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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest