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

Doug Lea dl at cs.oswego.edu
Mon Aug 3 14:10:35 EDT 2015

On 07/23/2015 10:23 AM, Doug Lea wrote:
> 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/

Thanks to those sending comments and suggestions! A few follow-ups:

> * 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

To elaborate a little: The G1 collector sometimes places memory
fences after reference writes. These tend to be most common where
they are least desirable in concurrent applications; for example
during producer-consumer element handoffs, which can significantly
impact performance. Some GC developers are looking into alternatives.

> ForkJoinPool ...  "Async" FJP mode is now probabilistically fair;

Thanks especially to Viktor Klang and Ron Pressler for helping
to refine this, and tease apart into two aspects (both of which
might be subject to further updates).

(1) Introducing a failsafe bound to avoid indefinite starvation
with unbounded loopy recursive tasks like ...
   class MyTask { ... void compute() { ... new MyTask().fork(); ...} }

The bound (of 1K tasks) forces worker threads to eventually try
looking elsewhere for tasks to execute.
By intent, eventually can be a long time.
The motivation is similar to spare-thread bounds -- to reduce
or avoid unbounded long-term resource issues without impacting
performance of well-behaved usages. There doesn't seem to be
a good reason to expose the bound as a tunable parameter.

(2) Providing a way to define tasks that might sometimes
prefer to poll external submissions rather than internal actions
like those in the above recursive loop. This amounts to exposing
ForkJoinPool.pollSubmission in ForkJoinTask, which in retrospect
was an oversight: pollSubmission is "protected" in ForkJoinPool,
but by Java protection rules was inaccessible from ForkJoinTask
subclasses, so needs an explicit relay method.

On 07/24/2015 02:52 PM, Doug Lea wrote:
> On 07/23/2015 02:55 PM, Dávid Karnok wrote:
>> 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.
> Thanks. I'm going to sit on this for the moment. One alternative is to add
> method isClosedExceptionally so that only those new Subscribers that care
> how it was closed need to arrange special handling.

I added the exception-replay -- it simplifies the closeExceptionally spec.
I also added an accessor for the exception for use in other contexts.

On 07/24/2015 04:26 PM, Doug Lea wrote:
> On 07/23/2015 06:35 PM, Greg Wilkins wrote:
>> Specifically that it is asymmetric and an error in the middle of a chain of
>> processors ....
> So should there be a SubmissionPublisher method along the lines of:
> onSubscriberException(Consumer<? extends Throwable> handler);

Actually, the handler (with two arguments) must be provided in
the constructor to be effective. Added.

I know that Greg still doesn't love some of the reactive-stream error
protocols, but adding this method covers the cases where a Publisher
or Processor knows how to cope with an onNext exception.


More information about the Concurrency-interest mailing list