来自 erlang 解决方案的博客文章：其中比较了 JVM 和 BEAM（erlang 的 VM），文章认为JVM没有用于高度优化并发的原语。
但是现在Java有了Loom虚拟线程，是否实现了与 erlang 的绿色进程相同的Actor模型？
其实，Java还有可能做得更好。在Java中，虚拟线程之间的不可更改性和状态隔离是可以选择的，而在erlang中，这种编程模型大多是强制性的。
尽管当涉及到并发工作负载的正确性时，不变性和无共享被认为是一种方式，但其中包含的隐藏的成本被人忽视。
至于GC方面，JVM是在另一个层面上；erlang的简单拷贝收集器的唯一优势不是GC本身，而是它从不可变的用户数据和非并发集合中享有的保证：不需要内存屏障barriers。但是：在进程间为了传输数据总是拷贝（~序列化）模型会不断产生有问题的实例。
Erlang GC并不是为巨大的堆而设计的，而且很可能受到Java中已经解决的暂停问题的影响。
从理论上看，虚拟线程的分配成本与erlang进程相当。一些线程的臃肿被封装在一个对象（FieldHolder）中，而这个对象对于v-threads虚拟线程来说总是空的。V-threads有~19个字段（有些小于8字节）+头的开销，在64位的虚拟机中，其浅层尺寸小于160字节。