title: How Akka benefits from ForkJoinPool?
body: <p><a href="https://doc.akka.io/docs/akka/2.5/dispatchers.html#default-dispatcher" rel="nofollow noreferrer">Akka docs</a> states that default dispatcher is a <code>fork-join-executor</code> because it "gives excellent performance in most cases".<br>
  I'm wondering why is it? </p>
  
  <p>From <a href="https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html" rel="nofollow noreferrer">ForkJoinPool</a></p>
  
  <blockquote>
    <p>A ForkJoinPool differs from other kinds of ExecutorService mainly by virtue of employing work-stealing: all threads in the pool attempt to find and execute tasks submitted to the pool and/or created by other active tasks (eventually blocking waiting for work if none exist). This enables <strong>(1) efficient processing when most tasks spawn other subtasks (as do most ForkJoinTasks)</strong>, as well as <strong>(2) when many small tasks are submitted to the pool from external clients</strong>. Especially when setting asyncMode to true in constructors, ForkJoinPools may also be <strong>(3) appropriate for use with event-style tasks that are never joined.</strong></p>
  </blockquote>
  
  <p>At first, I guess that Akka is not an example of case (1) because I can't figure it out how Akka could be forking tasks, I mean, what would be the task that could be forked in many tasks?<br>
  I see each message as an independent task, that is why I think Akka is similar to case (2), where the messages are many small tasks being submitted (via ! and ?) to the <code>ForkJoinPool</code>.  </p>
  
  <p>The next question, although not strictly related to akka, will be, <strong>why a use case where fork and join (main capabilities of <code>ForkJoinPool</code> that allows work-stealing) are not being used still can be benefited by ForkJoinPool?</strong><br>
  From <a href="http://letitcrash.com/post/17607272336/scalability-of-fork-join-pool" rel="nofollow noreferrer">Scalability of Fork Join Pool</a></p>
  
  <blockquote>
    <p>We noticed that the number of context switches was abnormal, above 70000 per second.<br>
    That must be the problem, but what is causing it? Viktor came up with the qualified guess that it must be <strong>the task queue of the thread pool executor, since that is shared and the locks in the LinkedBlockingQueue could potentially generate the context switches when there is contention</strong>.</p>
  </blockquote>
  
  <p>However, if it is true that Akka doesn't use <code>ForkJoinTasks</code>, all tasks submitted by external clients will be queued in the shared queue, so the contention should be the same as in <code>ThreadPoolExecutor</code>.</p>
  
  <p>So, my questions are:</p>
  
  <ol>
  <li>Akka uses <code>ForkJoinTasks</code> (case (1))  or is related to case (2)?</li>
  <li>Why <code>ForkJoinPool</code> is beneficial in case (2) if all that tasks submitted by external clients will be pushed to a shared queue and no work-stealing will happen?</li>
  <li>What would be an example of "with event-style tasks that are never joined" (case 3)?</li>
  </ol>
  
  <hr>
  
  <h2>Update</h2>
  
  <p>Correct answer is the one from johanandren, however I want to add some highlights.</p>
  
  <ul>
  <li><em>Akka doesn't use fork and join capabilities since AFAIK with the Actor model, or at least how we implement it, there isn't really a usecase for that</em> (from johanandren's comment).<br>
  So my understanding that Akka is not an instance of case (1) was correct.</li>
  <li>In my original answer I said that <em>all tasks submitted by external clients will be queued in the shared queue</em>.<br>
  This was correct but only for a previous version (jdk7) of the FJP.
  In jdk8 the <a href="https://github.com/openjdk-mirror/jdk7u-jdk/blob/f4d80957e89a19a29bb9f9807d2a28351ed7f7df/src/share/classes/java/util/concurrent/ForkJoinPool.java#L461" rel="nofollow noreferrer">single submission queue</a> was replaced by many "submission queues".
  <a href="https://stackoverflow.com/a/30085265/3517383">This answer</a> explains this well: 
  
  <blockquote>
    <p>Now, before (IIRC) JDK 7u12, ForkJoinPool had a single global submission queue. When worker threads ran out of local tasks, as well the tasks to steal, they got there and tried to see if external work is available. In this design, there is no advantage against a regular, say, ThreadPoolExecutor backed by ArrayBlockingQueue. [...]<br>
    Now, the external submission goes into one of the submission queues. Then, workers that have no work to munch on, can first look into the submission queue associated with a particular worker, and then wander around looking into the submission queues of others. One can call that "work stealing" too.</p>
  </blockquote></li>
  </ul>
  
  <p>So, this enabled work stealing in scenarios where fork join weren't used. As <a href="http://cs.oswego.edu/pipermail/concurrency-interest/2012-January/008987.html" rel="nofollow noreferrer">Doug Lea says</a></p>
  
  <blockquote>
    <p>Substantially better throughput when lots of clients submit lots of tasks. (I've measured up to 60X speedups on micro-benchmarks). The idea is to treat external submitters in a similar way as workers -- using randomized queuing and stealing. (This required a big internal refactoring to disassociate work queues and workers.) This also greatly improves throughput when all tasks are async and submitted to the pool rather than forked, which becomes a reasonable way to structure actor frameworks, as well as many plain services that you might otherwise use ThreadPoolExecutor for.</p>
  </blockquote>
  
  <ul>
  <li>There is another singularity that is worth mention it about FJP taken from <a href="https://grokbase.com/t/gg/akka-user/1562dcb4w6/too-many-scan-calls-when-profiling-my-akka-application#20150612bnb4gjnx7ygsdtphbbmq4iqg5a" rel="nofollow noreferrer">this comment</a>
  
  <blockquote>
    <p>4% is indeed not much for FJP. There's still a trade-off you do with FJP
    which you need to be aware of: <strong>FJP keeps threads spinning for a while to be
    able to handle just-in-time arriving work faster. This ensures good latency
    in many cases. Especially if your pool is overprovisioned, however, the
    trade-off is a bit of latency against more power consumption in almost-idle
    situations.</strong></p>
  </blockquote></li>
  </ul>