Drop Java 8 support to have a ForkJoinPool usage fix?

[migesok]

Hi!

May be I'm wrong but seems that Pekko does still support building and running on Java 8. Would you consider in the future raising the minimal JDK version requirement to at least 11?
I have a fix to contribute in the ForkJoinExecutorConfigurator but it relies on Java 9+ features of the ForkJoinPool, namely maximumPoolSize constructor parameter.

In a nutshell the problem is that during periods of prolonged CPU starvation, an Akka app (cluster + http) might slowly create more and more idle threads in the default pool until it becomes unresponsive or dies with OOM. Currently ForkJoinExecutorConfigurator does not specify maximumPoolSize which makes the pool effectively unbounded. We can use the default JDK common pool strategy there - parallelism + max spare threads count (default: 256) with the max spare threads count configurable.

[pjfanning]

• we build with Java 11 but target Java 8 compatibility
• Java 11 features can be accessed using Java reflection or we have the ability to build Java 11 targeted classes - see https://github.com/apache/incubator-pekko/blob/main/project/Jdk9.scala (but ignore the 9 in the name - JDK9 and 10 are no longer supported by Java implementations).
• You might find Java reflection is easier for this use case

[pjfanning]

you can also add custom dispatchers if you want to just solve this problem for yourself and not worry about patching this in Pekko - https://gist.github.com/yanns/f7da61c582ab1da3535d is an example

[migesok]

Thanks for the reply!
I have a custom dispatcher already but it is a bit error prone as there are places in the Akka ecosystem which reference "fork-join-executor" directly (mostly Akka Persistence and plugins) and this fix looks good to be everywhere by default. I feel a bit uneasy about making it JDK version dependent in the Pekko though.

My project is still on Akka 2.6.20 and migration to Pekko won't happen soon so all of this is not of immediate importance for Pekko and me. My question was more about current state and the future plans for JDK version support.

[pjfanning]

Dropping Java 8 support is not a big priority for us - there are pros and cons. The biggest con is that many users still use Java 8.

I raised #483 anyway - for a solution to this problem that doesn't involve removing Java 8 support.

[migesok]

I understand. Thank you for your time!

[pjfanning]

@migesok I have a PR associated with #483 but it is awkward to write using Java reflection and hard to unit test due to the order in which the Pekko build runs. In the end of the day, we should consider fixing it so that users can use the custom dispatchers everywhere in Pekko. Would you be able to provide specific examples of where you are forced to use to use the default fork-join-executor? At some point, users are going to want Project Loom based executors, for instance.

[lolczak]

The JDK 8, which was released almost a decade ago, is quite old. Would you like to continue supporting it? In my humble opinion, it would be wise to switch to the newer JVM.

[pjfanning]

Unfortunately, there are people who think we should support Java 8 still and Java 8 still gets security patches - so it is viable for users to stick with it.

[He-Pin]

We just starting to migrate from JDK 8 to JDK 11, slow progress...

[He-Pin]

Akka just dropped JDK 8. Will pekko drop JDK 8 in pekko 1.2.x?

[mdedetrich]

Akka just dropped JDK 8. Will pekko drop JDK 8 in pekko 1.2.x?

Most likely not, there are a lot of people that use JDK 1.8.

What's more likely is that we will start doing multi release jars so we can use functionality in newer JDKs