Hacker News new | ask | show | jobs
by bitwalker 1178 days ago
The BEAM is so much more than just a green thread runtime - and it is not straightforward at all to just "bring it over" to another virtual machine, the entire BEAM VM is designed around the scheduler, and core features such as signals (used most notably for links/monitors, but also for a number of other system features) and messaging, are deeply integrated with the scheduler; as are system tasks, execution of NIFs (natively-implemented functions), and more. Furthermore, the schedulers are adaptive to the amount of work in the system, and the behavior of the other schedulers, i.e. they aren't just simple work-stealing queues for green threads. Over 20 years of engineering effort have been invested in this system, and it is highly optimized for the types of workloads that Erlang is used for.

In my opinion, trying to replicate ERTS on top of another virtual machine either requires making that virtual machine more like the BEAM, or will end up always playing catch up with the BEAM itself in some aspect. That's just my two cents though.

1 comments

I am well familiar with BEAM, and my fascination with it ~20 years ago was one of the things that inspired me to become a VM engineer. Bringing that over to the JDK was, indeed, a large effort, but we are a large, well-funded team.
The guy you are responding to is an Erlang VM engineer, just sayin'
And, as a JDK engineer with Erlang experience, I'm just sayin' that as of the past six months, the JDK has all the primitive building blocks required for a very efficient Erlang runtime. Even the thread scheduler is not built into the JVM but written in Java, and will soon be made completely pluggable. Any scheduling algorithm that Erlang wishes to employ can be provided as a library on top of the JVM. If I've missed anything, we'll consider adding it.

It's been a dream of mine to port BEAM to the JDK to give Erlang much better performance and greater visibility. Unfortunately, this work can't be funded as there's insufficient demand for Erlang. If the Erlang community does it, however, it could increase its evolution velocity, improve performance, and give it higher visibility.