Akka's data structures

[yawnt]

Akka.JVM uses (I'm assuming for performance reasons) some JVM data structures, which are not available in Scala-js (eg: Deque)

Akka currently only uses a small subset of methods from each class.

There are two ways we can fix this: either we completely port the required data structures to Scala-js OR we can do something like this:

in jvm/src/main/akka/util/

class AkkaDeque[A] extends Deque[V] {
  def methodWeNeed = threadLocalMethod()
}

in js/src/main/akka/util/

class AkkaDeque[A] {
  var value: A = _
  def methodWeNeed = ???
}

On one hand, solution 1 requires a lot of effort on the Scala-js side, but it doesn't require any changes to Akka itself.

On the other hand, solution 2 would require some changes and it might be a bit more clumsy in case you need new methods from the underlying collection (you need to manually add the method to AkkaDeque), but it doesn't require nearly as much effort on the Scala-js side

Thoughts?

@rkuhn @andreaTP @andreaferretti

[andreaTP]

java.util.ConcurrentSkipListSet is on the way, if there are no other big steps let just wait for 0.6.4 :fishing_pole_and_fish:

[rkuhn]

Changing the Akka codebase itself is not in the cards, especially since our usage of these special APIs are there for performance optimizations and adding indirection will have measurable negative effects. The JS port will have to either diverge where these APIs are used or reimplement them.

[yawnt]

Just to make sure I understood correctly, are you against refactoring akka-actor such that it implements the CrossProject standard or just against changing data structures in Akka itself? The CrossProject means having 3 folders inside akka-actor: js/, jvm/ and shared/

This is also connected with #14

[rkuhn]

As I commented in #14 we will not currently refactor the Akka codebase to implement cross-compilation for different runtimes, but I sketched how to do that in the Akka.js project itself. The background is that Akka.js needs to become a mature and battle-tested project before we can add it to our codebase, and there is no point in moving around files in the akka/akka repository before that is the case.

[yawnt]

With regard to the cross-compilation layout, I understand your point and agree. So I would propose something like this and I would love to have your feedback:

• Akka.js stays in its own repo and uses a git submodule (or something akin) to get code from Akka.JVM
• akka-actor/ in Akka.JVM : it would be nice if they could be separated in:
  • akka-actor-base which includes 95% of the code
  • akka-actor-jvm which includes some trait you mixin in akka-actor-base to provide the full current Akka.JVM codebase

To reiterate, I just need a way to import non-JVM specific code which right now is intertwined with JVM code (meaning I can't just import the whole file). Using that layout we can exclusively depend on akka-actor-base and easily update Akka.js when necessary.

Thank you for your feedback, it's very much appreciated :) :+1:

[sjrd]

For the record, ThreadLocal is supported in Scala.js. Its implementation is there: https://github.com/scala-js/scala-js/blob/master/javalanglib/src/main/scala/java/lang/ThreadLocal.scala

[yawnt]

You are right of course, it was a poor choice. Another example might be Deque which cannot be ported to Scala.js because of its blocking API (eg: poll). I was also wondering why Akka uses Deque when it's only using methods which are also available in Queue

I changed the example to use Deque :), thanks!

[rkuhn]

As discussed with @andreaTP at ScalaDays we should not try to move things to JS that don’t make sense there, instead just rip out these parts in the Akka.js port—and we should really think of that as a port and not cross-compilation for these purposes. Mailboxes, Dispatchers, ReflectiveAccess, Scheduler will have to be implemented differently on this platform, there is no way around such a split. The benefit for users will be that the adaptations to JS are all invisible to them, hidden in the machinery.