2 ms·
> [...] but you can have those millions of processes on the JVM, too [...] In theory, yes. In practice, it's very difficult. JVM thread corresponds to a thread
by dozzie 11y ago
> [...] but you can have those millions of processes on the JVM, too [...]
In theory, yes. In practice, it's very difficult. JVM thread corresponds to
a thread of host OS. Spawning and keeping those is very slow and expensive
compared to Erlang's processes. You could have a pool of pre-spawned workers,
but suddenly you can't spawn a worker for each connection and hope it will all
work; you need to manage the pool. You also could try to implement green
threads in JVM, as they are in Erlang, but you would need an entirely new
compiler to insert yield points at appropriate places, or else you would get
exactly the same problems with green threads as everywhere else.
Under JVM you just don't spawn a thread for each and every activity, because
you would choke your system. The whole point of developing Erlang was to allow
exactly this programming style in a manner safe against processing
congestion.
- acjohnson55 11y agoHow does Akka stack up in regards to providing these attributes on the JVM?
- pron 11y ago> you need to manage the pool. You also could try to implement green threads in JVM, as they are in Erlang, but you would need an entirely new compiler to insert yield points at appropriate places. I am talking about a new compiler. An Erlang compiler. The JVM is a virtual machine. Erlang is a language. We've already proven you can run Erlang on the JVM quite well, and that was before many pertinent improvements to the JVM and its ecosystem.
- dozzie 11y agoJVM still lacks some serious functions, namely, links and monitors. I'm not that sure you can emulate those on JVM reliably without implementing them as fundamental operations. And then, there's still problem of interoperability. Even when you write your code in Erlang@JVM, it still needs to talk to Java code, which doesn't have yield points.
- pron 11y ago> JVM still lacks some serious functions, namely, links and monitors. I'm not that sure you can emulate those on JVM reliably without implementing them as fundamental operations. You don't emulate them; you implement them -- just as BEAM does. Having them baked into the runtime serves no purpose. The JVM operates at a much lower level than BEAM -- just as BEAM is implemented in C, it could be implemented in Java, except that the really hard parts (JIT and GC) are already taken care of. Think of Java as C + JIT + GC. > it still needs to talk to Java code, which doesn't have yield points. That's not a problem. First, Erlang code talks to C code, which doesn't have yield points, either. Second, the JVM doesn't need to rely on yield points as much as BEAM does, because it is much more kernel-thread-friendly than BEAM.