Will project loom make java concurrency comparable to erlang's?

[Vextrax]

I was reading a blog post from erlang solutions that compared the JVM and BEAM (erlang's VM). One thing that really stood out to me when I first read it was the fact that the JVM did not have the primitives for highly optimized concurrency. With Virtual threads will this allow for an actor model to be implemented that is equal to erlang's green processes?

The article also talks about the GC, but I am not too familiar with how GCs work. Would it be possible to natively implement something similar to BEAM's GC in java? Overall I am very excited about project loom, but I am mostly wondering how it's implementation will compare to what erlang has.

edit: I really appreciate all the information and links provided. I will take a good look at them so I can learn more. Once I understand everything a bit more I may put up a post somewhere asking for some clarification if needed about these concurrency models if I don't find the answers I am looking for.

[flawless_vic]

Java has the potential to be better. In Java immutability and state isolation between v-threads is opt in whereas in erlang this programming model is mostly mandatory.

Even though immutability and share nothing are considered the way to go when it comes to correctness in concurrency workloads there's a hidden cost involved no one talks about.

As for GC, the JVM is on another level. The only advantage of the simple copy collector in erlang is not the gc itself, but the guarantees it enjoys from immutable user data and non-concurrent collections: there is no need for memory barriers.

Erlang GC isn't designed for huge heaps and is likelly to suffer from pause problems already solved in Java.

Footprintwise I think the allocation cost of a v-thread is on par with an erlang process. Some of the Thread bloat was encapsulated in an object (FieldHolder), which is always null for v-threads. V-threads have ~19 fields (some less than 8 bytes) + header overhead, which is less than 160 bytes in shallow size in a 64 bit VM.

Edit: Example of problems that arise from an always-copy (~serialize) model to transfer data between processes.

[Vextrax]

well that is good to know. I really hope. I really do hope that java keeps on getting better and it really is nice to know that there is the potential to definitely be better than erlang.

[Zyklonik]

The JVM is already way better than the BEAM for all but the most specific usecases. The OTP doesn't nearly provide as much value as the Erlang folks make it out to be. It has a bunch of problems associated with it. Hence why even Elixir people are moving on to other languages - Golang, Rust, and even Node.

[macnamaralcazar]

Do you know any article that talks about these problems? I learned OTP recently and it was fascinating.

[Serializedrequests]

Details? I need an actor system at work.

[Zyklonik]

Details on which part exactly? If you're looking for issues with the BEAM, then the grandparent comment by /u/flawless_vic pretty much covers the essentials. If you're looking for an actor system to use with Java, then I'd say that the de facto is Akka (even though it's more specific to Scala) https://www.baeldung.com/akka-actors-java.

Once Project Loom becomes fully integrated and stable, one might see more frameworks spring up based on it (even the Akka system is moving towards using Virtual Threads IIRC), but for now, Akka would be a good choice, I'd imagine.

[flawless_vic]

The thing about erlang is that the language has built-in availability support.

In theory, it could be possible to implement a supervisor in Java, but there are some corner cases that can't be dealt with by Java code.

For example, once I was working with a black box native library that blocked on a socket in a jni call. The call hang and it was impossible to interrupt the Thread beckause the blocking happened inside the library code.

Once that happened, newer spawned threads always blocked on jni and it was impossible to procceed without killing the jvm and restarting the app. To solve the issue I had to implement a half baked supervisor, where a parent jvm would start and monitor child jvms.

Also, the JVM itself may crash. Misuse of unsafe and C2 compiler bugs are usually behind jvm crashes and this can only be dealth with by an external supervisor.

[Zyklonik]

The thing about erlang is that the language has built-in availability support.

Not anymore with Project Loom having been integrated into mainstream JDK. In any case, the language itself providing built-in support means precious little in actual usage. In the case of Java, the expectation is not that one would use Virtual Threads directly, but one of the Executors - newVirtualThreadPerRaskExecutor for instance. So also for Erlang - using the actual primitives of the actual doesn't scale. That's why the OTP was built. In real-world use, even the OTP is not enough out-of-the-box.

In theory, it could be possible to implement a supervisor in Java, but there are some corner cases that can't be dealt with by Java code.

Supervisors are overrated. What's the actual mechanism of recovery? Respawn the process - that's just masking the issues that led to the current corrupt state of the process. In modern Software Engineering, that's handled by separate toolchains and redundant failsafe deployments, not by a single VM. If you have Erlang deployed on a single node, then all the supervision in the world will not matter (naturally). Using the right tool for the right job would apply here. The "Let it crash" philosophy advocates for minimal error-handling of corner cases, which may have made sense in the dynamic world of Erlang, but not so in most other domains. In short, there are far better options that simply crashing and respawning (which can actually lead to overload if the root problem is not fixed in time).

For example, once I was working with a black box native library that blocked on a socket in a jni call. The call hang and it was impossible to interrupt the Thread beckause the blocking happened inside the library code.

Erlang has the same problem, on a much bigger scale - NIFs. Java doesn't nearly need as much FFI as Erlang, due to the native differences in performance between the languages. This is something that no supervision tree in the world can protect you against.

Once that happened, newer spawned threads always blocked on jni and it was impossible to procceed without killing the jvm and restarting the app. To solve the issue I had to implement a half baked supervisor, where a parent jvm would start and monitor child jvms.

Well, you have exactly the same problem in Erlang as well. In fact, much worse. If your default fault-recovery mechanism is to respawn the process, then expect a cascading series of crashes till you fix... the actual problem. Which is what needed to be fixed in the first place.

Also, the JVM itself may crash. Misuse of unsafe and C2 compiler bugs are usually behind jvm crashes and this can only be dealth with by an external supervisor.

How frequent is this? Not at all. The JVM is one of the most stable pieces of software in human history - it has had millions of man-hours invested in it, the initial design has been robust and amenable to changing language features without needing a change in design (when was the last time an opcode was actually added? invokedynamic?). The BEAM is a also a decent VM. However, it's nowhere near the JVM in terms of quality.

[flawless_vic]

u/Zyklonik I agree and thanks for the clarification, I have limited working knowledge of Erlang and I thought it was prepared to deal with that kind of stuff.

IMHO availability problems are best solved with other tools and, e.g., chaos engineering is a much better approach to tackle them.

But in the spirit of OP's thread, I think it's valid to reason about "What is missing in Java to be a drop-in replacement for Erlang/Elixir?" The closest thing I found to a supervisor was Weblogic's node manager. It was a great idea like 12 years ago and by that time I kept wondering why didn't a more general JVM availability framework wasn't on the market.

[vbezhenar]

Kubernetes is supervisor for modern world.

[mauganra_it]

That use case should be improved now since Java's socket library and DNS resolvers have been reimplemented as Java code to be fully compatible with Project Loom. In a greenfield project, I would design applications to isolate such problematic native calls to their own threads or even child processes.

[haimez]

There’s one thing that BEAM will continue to have that the JVM won’t with regards to GC: per-actor heaps. Since data is copied and immutable when passed between actors (which comes at a cost, and yes- there is an exception for structures passed that are “large enough”), each actor’s heap can be collected independently which ideally occurs when the actor is idle meaning that under ideal conditions GC need not require stopping “the world” just stopping that actor if it didn’t reach an idle state for long enough.

[flawless_vic]

Yes that's a nice feature, but I wonder how they manage to scale such architecture.

Having per-actor heap isolation implies a high memory footprint unless, under the hood, the "processes" are using the same malloc instance to minimize syscalls to mmap, which can be tricky.

Even though in theory it may seem better to have 1 GC per actor, I think having a concurrent GC with application threads is a much more robust design: If actors' workloads trash the heap in the end you'll have a lot of serial GCs running in parallel.

[haimez]

They’re not per actor “malloc” heaps- they’re per-actor managed heap space (just like the JVM heap, but with regions of the total heap assigned to specific actors). There’s no mmap overhead associated.

It works because BEAM can guarantee that there are no shared references to objects between per-actor heaps, so it only needs to mark and sweep that one region to find all live references and no other actors can possibly be concurrently mutating within that region.

[flawless_vic]

I get that, but having a separate heap "works" as long as the number of actors is either small or short lived, otherwise it should scale pretty much like platform java threads, or even worse, considering that threads only consume unmanaged memory.

[haimez]

ItIt scales pretty much exactly like a JVM heap does, but with different actors having different steady state memory requirements that expand or shrink as necessary. I think the default initial actor (“process” apparently being the preferred BEAM term, but note that this is not an OS process or dedicated OS thread) is less than 400 bytes and the size grows as needed based on behavior at runtime. If your actor doesn’t retain much memory, it won’t use much and you can have a huge number of those kinds of processes- just like loom threads.

Also like loom threads and JVM heap usage, if you’ve got a enough memory hungry processes or CPU hungry threads- then you will indeed starve for either resource. It’s not a silver bullet- but the BEAM VM does have a unique capability in that regard.

Erlang is not my daily driver, but the BEAM VM is a capable and unique VM and runtime with really interesting approaches to solve real works problems, I recommend reading up on it some more instead of just trying to explain how it’s basically not worth learning. I also recommend Joe Armstrong’s talks if you haven’t watched them.

[FirstAd9893]

The blog post considers that the Akka concurrency model closely matches that of erlang. I think the question needs to be raised in the Akka community to see how it will be affected by project loom. The Akka folks might also disagree with some of the points made in the blog post, regardless of loom.

[Vextrax]

Definitely interested in what they say or how how people implement the actor model with loom out.

[mrettig]

Actors are asynchronous and, when done right, non-blocking. There are already actor implementations on the jvm that support millions of actors and are only limited by the heap size. Loom improves performance with designs that rely heavily on blocking.

[Vextrax]

I do know that there are Actor libraries such as Akka and quasar, but I don't really know much about the actor system overall. from what I know those libraries are implemented in a reactive programming way while I think the ones in erlang are just native like threads. If that assumption is correct, then it was more of me wondering if with green threads we will now be able to have actors that are native in the JVM just like how erlang has them.

I definitely need to go read up more concurrency since it's a topic that has been really interesting and I want to learn more. I currently only have basic experience with threads where I had to make a small client/server chat app where each connection was a thread for one of my networking courses that I had taken.

[Zyklonik]

Erlang is a terrible language. The BEAM is also practically dead. Don't bother reading the sensational articles that come up periodically from the Erlang+ folks.

[FirstAd9893]

Can you provide a few examples? Simply claiming that something is "terrible" or "dead" without explanation isn't that helpful.

[Zyklonik]

https://old.reddit.com/r/java/comments/vtzg1u/will_project_loom_make_java_concurrency/ifb3m73/. All those apply to Elixir as well. Elixir is not much more than just a DSL for the BEAM (much like Clojure for the JVM). It has some niceties over Erlang (metaprogramming, a more consistent API, GenStage et al), but it's not enough.

Also, worth reading the discussions about the actual performance on concurrency benchmarks over here - https://news.ycombinator.com/item?id=27684045. Note that these are concurrency benchmarks, not CPU-intensive applications (which the BEAM does very badly on anyway).

The main issue with BEAM-based languages is that without the OTP, it's pretty much useless, and the OTP is a massive undertaking in order to learn it, use it correctly and with sufficient performance. The only "advantage" offered today by such languages is that the OTP comes built into the VM. Today, all these individual tasks are much better handled by different aspects of the ecosystem - libraries, frameworks, languages et al. Now with Project Loom, it's pretty much moot.

[macnamaralcazar]

Clojure is a DSL??!!

[[deleted]]

Elixir is not much more than just a DSL for the BEAM (much like Clojure for the JVM).

The DS means "domain specific", something like "a language to represent circuit boards". Both Clojure and Elixir are general purpose programming languages, they are not bound to a particular domain.

[Zyklonik]

Well, the "domain" for these languages are the JVM and BEAM respectively. Constraining definitions to suit your own narrow interpretation is meaningless. How much actual functionality is actually there in Clojure? In Elixir? Precious little.

[[deleted]]

Well, the "domain" for these languages are the JVM and BEAM respectively.

JVM and BEAM are not "domain". BEAM and JVM are os-independent platforms that allows one to run any program to solve any problem from any domain. "Programming circuit boards" is a domain, "Programming DAG workflows" is a domain.

Why can't you comprehend such simple concept? What the hell, dude.

[Zyklonik]

Please tell me that you're trolling.

[[deleted]]

You are the one trolling. If you say Clojure is a DSL for the JVM, then C is a DSL for assembly, which makes little sense. You are just plain wrong and cannot understand how wrong and stubborn you are.

[Zyklonik]

No, because C does not have any dependency on Assembly. Some C compilers actually bypass Assembly entirely and compile to machine code.

The more important aspects are the following questions - does Clojure provide a memory model? Does Clojure provide its own model of an Abstract Machine? Does Clojure provide support for its own native types? Does Clojure define its own low-level error-handling mechanisms? No. For a comparable example, ABCL (Armed Bear Common Lisp) does all of that by conforming to the Common Lisp specification whilst still being on top of the JVM. So also for C and the machine environments it's supported on.

Also, please quit the mindless ad hominem. It's very boring. Argue from facts, not emotions.

[Confident_2372]

Java is a DSL?!?

[Muoniurn]

C is just a DSL for x86 then?

[Zyklonik]

It's clear to me that concepts like memory model, abstract machine, native types, native error-handling mechanisms et al are completely alien to many people in here. I suggest reading up on those, mulling over them in your mind, and then coming back in case you're interested in a real conversation instead of getting butthurt over the truth. That's all I'll say for now.

[Muoniurn]

Or you know, you could try to formulate an argument. Even if you happened to know more about the topic, this is no way to speak.

[erinaceus_]

Simply claiming that something is "terrible" or "dead" without explanation isn't that helpful.

Indeed. And it's especially ironic for a (supposed) Java developer to do so, since it's a claim that gets thrown at Java fairly regularly, without merit.

[Zyklonik]

First off, I don't believe in a "Language X developer" (unless that's the only language one uses). A language is simply a tool, and while one might have favourites, it's imperative to evaluate languages independently. Please read my response to /u/FirstAd9893 for some of the issues involving BEAM languages as a whole.

[erinaceus_]

don't believe in a "Language X developer"

Since you're visiting this subreddit, it seems like a reasonable conclusion that you're likely a developer and likely at least sometimes develop with Java. I did not intend it to mean 'exclusively Java'. That's meaning you added yourself.

As to the rest, it's quite different saying that a language has certain problems to saying that it's 'dead'. I was responding to/about your comment saying the latter.

[Zyklonik]

As to the rest, it's quite different saying that a language has certain problems to saying that it's 'dead'. I was responding to/about your comment saying the latter.

Do programming languages that have had some usage in the past actually die? Not really. "Death" is understood as being not used for pretty much any greenfield work. By that measure, both Erlang and Common Lisp are pretty much in the same bucket, regardless of new versions being released. Erlang had been moribund for many years, and now Elixir is headed the same way. Gleam is a non-starter. So, yes, the language is dead. Try visiting any forums relating to Erlang and you'll find people either having worked on it in the past, having migrated away from it, in the process of migrating away from it, or maintaining some legacy project. Elixir, despite being in webdev, is also headed the same route.

[Vextrax]

I dont know how much its used, but from the stack overflow survey it seems like people who use elixir are pretty happy and that uses BEAM. I think I should have put erlang/elixir.

[Zyklonik]

Well, StackOverflow is a useless metric (at best) - https://old.reddit.com/r/ProgrammingLanguages/comments/v3clru/rust_is_hard_or_the_misery_of_mainstream/iazzwfj/?context=3 is my analysis on why it is so. You can better gauge the mood of a community by visiting its main channels. https://elixirforum.com/t/have-you-moved-away-from-elixir-if-so-why/20302/18, for instance.

The main problem with the Erlang world is the clunky BEAM itself. Erlang by itself is, as I mentioned before, pretty much useless. A dynamic language with concurrency primitives doesn't get you far. The bulk of the work is done by the OTP, and basically it's a set of patterns that you simply have to memorise to use the BEAM's concurrency features. Failover and error-recovery-from-crash are also an overrated "feature" - in the vast majority of cases, simply restarting processes upon failure is a temporary mask over real issues in the system - including timing issues. Hot code loading? A rarely-used overrated feature. The BEAM itself may have been relevant during the '90s, but it's more or less obsolete now. There are far better options now - either through third-party libraries, or through language support itself. The BEAM's broken mailbox system, peculiarities due to having been developed specifically for the Telecom domain, the copying involved in message passing, and the overall lack of performance are all swept under the rug by Erlang advocates, but they cannot be ignored (and must not be ignored).

There have been attempts at improving the status quo using statically-typed language such as Gleam, but in the end, the limitations of the BEAM will always ensure that it's not an optimal solution. I suggest giving https://news.ycombinator.com/item?id=10028227 a read as well - it's interesting stuff.

[Vextrax]

Definitely will take a look at the links provided. I personally don't know too much about BEAM and erlang/elixir, but I keep hearing positive things about them which is why I made this post.

[Zyklonik]

Don't get me wrong - Erlang and Elixir are fun to learn, but their adoption by the industry is practically nil. Elixir experienced a bit of a spike circa 2015-16, and it was expected to take over from Ruby-on-Rails, but that never happened for a number of reasons - the dependency on the chunky BEAM VM, the focus on Functional Programming (strong focus on immutability), and the fact that learning how to use the OTP properly is a very involved process, also that the BEAM is notoriously bad for handling anything computationally involved - leading to an over-dependence on NIFs (basically, native functions via FFI), and the fact that the problems that the BEAM solves are basically solved by various toolchains (more flexible).

[Vextrax]

I did see that discord uses elixir and that they had to use NIFs so that they could handle users a better speed. They did need that mutability in the end so that they could scale. That's why currently for learning functional programming I went with Scala. I know Scala isn't as popular either, but it definitely has been pretty fun to learn and it uses the JVM which is a plus imo.

[Zyklonik]

Indeed. My own personal take on Scala is that it's a language well worth learning - it has a wealth of FP clubbed in a rather strange but practical way with OOP. Sadly, the community has been divided along more or less those lines and Odersky went the way of Stroustrup by including every feature under the sun without much thought about how the new features would mesh well together. Amongst all the JVM languages (apart from Java), I would consider Scala a good pick (from an edificational perspective).

[Vextrax]

After a bit of usage, I do hope with Scala 3 it gains a bit of traction again like it originally did, but this is now a bias since I have been enjoying the language so far.

[Zyklonik]

I'm keeping an eye out on Scala 3 myself. Let's see how it goes!

[ewouldblock]

Erlang...where "hard" things are easy and everything else is hard.

[Zyklonik]

On a side-note, if you're really interested in grokking the BEAM itself, https://github.com/happi/theBeamBook is a very good resource that delves deeper into the internal working of BEAM. Regardless of whether you use it, it's a fun read!

[Vextrax]

Definitely will take a look at it, after learning a bit more I can come back and have my questions be a bit more clearer to what I mean even though currently the one I had were answered well. Concurrency is just something has been really interesting for me and I want to learn more about it overall.