Prepare for Loom

[He-Pin]

JDK 21 will be released very soon and I saw some libraries are starting to prepare their library for Loom.
eg:
graphql-java/graphql-java#3317
reactor/reactor-core#3566

I think pekko should be prepare for that too, plus no performance regression; I mean reduce the usage of synchronized (which maybe changed in later JDK release too) not let an Actor <-> VirtualThread.

[mdedetrich]

So one thing to note here is that if we use Loom unless we can put the functionality into another artifact we are basically going to be forcing users to use the newest JDK. There are hypothetical solutions for this, i.e. sbt/sbt#7174 (comment) would allow us to release pekko with class filees that are specific to a JDK allowing users of Pekko to automatically get the features of Loom if they are using latest JDK will still supporting older JDK's

One other thing to note is that at least if we are talking about performance, I am not entirely sure that Loom is going to give us benefits. Actors is another design to solve some of the problems that Loom does, i.e. the messaging protocol of actors is immutable data which is one of the reasons why they perform so well and Loom isn't really going to get us much here given that logic in Actor's are guaranteed to execute on the same thread (loom gives us performance benefits when context switching).

Loom can provide performance improvements if we are talking about Future comprehension, but this is kind of orthogonal to Pekko (i.e. we would get these improvements automatically if someone was to provide an ExecutionContext backed by Loom) and I would presume a better way to solve this problem is to just provide these ExecutionContext's for Pekko as a separate artifact (even library) for the Pekko users that use Loom.

In essense Loom is probably more useful for those who are stuck on blocking IO/logic in Java world and/or use effect IO types such as Cats Effect/ZIO. Akka/Pekko doesn't do this at least in areas which are performance sensitive (and we have tricks such as ExecutionContexts.parasitic)

[He-Pin]

@mdedetrich I mean we can update some code with LockSupport instead, user can choose to use loom and don't want to be affected.

Another thing is , we may want to make use of multi-release jars too, Actor is a very lightweight and current the Loom's VirtualThread is scheduled with ForkJoinPool too, let's see how the community use the Loom before we do the actual move.

[pjfanning]

Partially related to #482

For me, we get greater results by ensuring that users can use custom dispatchers wherever they need to within Pekko instead of having to use the default one. The OP of #482 claims without detailed examples that Pekko doesn't let you control which dispatcher is used in all cases.

It is easier build-wise for us to have Pekko core built with Java 8 or 11 and separate jars which have add-on features that can be used by users of newer Java versions.

[mdedetrich]

For me, we get greater results by ensuring that users can use custom dispatchers wherever they need to within Pekko instead of having to use the default one.

Yeah I think this is the best course of action for now, and Pekko can provide custom dispatchers/ExecutionContexts that use Loom's VirtualThread's in jars that are built for JDK 21 separately.

The OP of #482 claims without detailed examples that Pekko doesn't let you control which dispatcher is used in all cases.

Honestly I think the best way to solve these issues is to use multi-release jar's but we would have to adjust sbt build so that this can be supported (if that can even work, it might only be possible in sbt 2.x)

[He-Pin]

@pjfanning That's true, I was want to do some clean up of threadlocal leak but can not be done with akka, want to submit a pr to pekko to fix that here later.

[pjfanning]

We need to look at all uses of ThreadLocal and see how we might be able to find an alternative mechanism based on low latency caches or if we need to make this pluggable so that Loom users can use cached based implementations while older JVM users would still use the ThreadLocal-based implementations.

Scoped Values (Java 20 and above) could be an option to replace ThreadLocal values that are immutable.

[pjfanning]

The main Pekko code base does use ThreadLocal in a few places. A class that gets used a lot is ThreadLocalRandom and I can't find much discussion of what the alternatives for ThreadLocalRandom are. A ScopedValue<Random> might work well in Java 20+.

[jxtps]

Any updates on this?

I'm interfacing with a significant body of synchronous legacy code and need to make web requests deep inside those stacks.

It is not really feasible to rewrite the code to be async, so it would be fantastic to be able to have the Pekko thread pools be backed by Loom so I don't accidentally run out of threads.

[pjfanning]

#1436 is in Pekko 1.1.0. This is the only change that we have made in this area.
I would recommend thoroughly testing any setup that uses a Virtual Thread dispatcher because I am not aware of anyone who has used it in production yet.

[He-Pin]

https://openjdk.org/jeps/8337395
JEP draft: Adapt Object Monitors for Virtual Threads

We have encounter several deadlock in production, I think this can only be experimental.