Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Erlang/OTP: Garbage Collector

medium.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: Erlang/OTP: Garbage Collector

#51

Post by voicedYoda »

weatherlight wrote: post #49
pron wrote: post #47

Earlier quoted context omitted.

> BEAM doesn't support mutation, the JVM does. that's a big plus in the BEAMs corner. The JVM supports languages with mutation or without. That x86 supports mutation doesn't hinder, say, Haskell from being efficiently compiled to it. > Also when two BEAM VM speak to each other its as if they are just one machine. no serialization de serialization of data, no protobufs, etc. It's all just primitives being sent between…

It's important to highlight some key differences between the JVM and the Erlang VM (BEAM) when it comes to accommodating language semantics, fault tolerance, and process isolation. The JVM is designed as a general-purpose VM, aiming to accommodate a wide variety of languages with different semantics. This broad scope can sometimes lead to compromises when it comes to optimizing for specific language features or use c…

Thank you for writing this out. I appreciate it.

Re: Erlang/OTP: Garbage Collector

#52

Post by bitwalker »

pron wrote: post #42
bitwalker wrote: post #27

Earlier quoted context omitted.

I really strongly doubt that GC is a bottleneck for Erlang programs on either the BEAM or the JVM - the sophistication of the scheduler, and the way various language primitives interact with it, is where the BEAM is almost certainly gaining an edge over the JVM. That said, I'm sure there are a subset of programs that _would_ be faster on the JVM, just depends on what metrics are being compared.

> the sophistication of the scheduler, and the way various language primitives interact with it That was brought over to the JDK six months ago. The JDK can now spawn millions of Erlang-like processes ("virtual threads") per second. Erlang is a great inspiration and it does incredibly well with the development resources available to it, but it's hard to compete with the level of engineering investment in the JDK and…

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.

Re: Erlang/OTP: Garbage Collector

#53

Post by pron »

weatherlight wrote: post #49
pron wrote: post #47

Earlier quoted context omitted.

> BEAM doesn't support mutation, the JVM does. that's a big plus in the BEAMs corner. The JVM supports languages with mutation or without. That x86 supports mutation doesn't hinder, say, Haskell from being efficiently compiled to it. > Also when two BEAM VM speak to each other its as if they are just one machine. no serialization de serialization of data, no protobufs, etc. It's all just primitives being sent between…

It's important to highlight some key differences between the JVM and the Erlang VM (BEAM) when it comes to accommodating language semantics, fault tolerance, and process isolation. The JVM is designed as a general-purpose VM, aiming to accommodate a wide variety of languages with different semantics. This broad scope can sometimes lead to compromises when it comes to optimizing for specific language features or use c…

OpenJDK's new GC doesn't require STW pauses, the JDK offers preemptive scheduling for millions of threads as well as supervision trees -- although, to be fair, these are recent changes that have, at least in part, been inspired by Erlang. All that is on top of one of the world's most capable compilers. I have long admired Erlang and its passionate community as well as how much they've been able to accomplish (and, as a VM engineer, studied its design), but between passion and being an actual top-tier competitor there's a certain reality gap.

Re: Erlang/OTP: Garbage Collector

#54

Post by pron »

bitwalker wrote: post #52
pron wrote: post #42

Earlier quoted context omitted.

> the sophistication of the scheduler, and the way various language primitives interact with it That was brought over to the JDK six months ago. The JDK can now spawn millions of Erlang-like processes ("virtual threads") per second. Erlang is a great inspiration and it does incredibly well with the development resources available to it, but it's hard to compete with the level of engineering investment in the JDK and…

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 (…

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.

Re: Erlang/OTP: Garbage Collector

#55

Post by omginternets »

pron wrote: post #41
omginternets wrote: post #34

Earlier quoted context omitted.

I think you may be missing the point. What the JVM doesn't have is elaborate optimizations to support copies, e.g. a generational GC.

The JVM has a selection of four generational GCs. Two of them are the most sophisticated GCs available anywhere. It's not a matter of some unique brilliance. Java is simply in such high demand that it has the sufficient resources to have state of the art optimising compilers and GCs.

Really? I had no idea. Can you suggest further reading?

Re: Erlang/OTP: Garbage Collector

#56

Post by omginternets »

NobleExpress wrote: post #39
omginternets wrote: post #34

Earlier quoted context omitted.

I think you may be missing the point. What the JVM doesn't have is elaborate optimizations to support copies, e.g. a generational GC.

Hm? G1 is a generational GC? And so is Serial/Parallel. And work on generational ZGC is ongoing [1]. Not sure what you're referring to here. [1]: https://openjdk.org/jeps/439

I was mistaken!

Re: Erlang/OTP: Garbage Collector

#57

Post by weatherlight »

pron wrote: post #53
weatherlight wrote: post #49

Earlier quoted context omitted.

It's important to highlight some key differences between the JVM and the Erlang VM (BEAM) when it comes to accommodating language semantics, fault tolerance, and process isolation. The JVM is designed as a general-purpose VM, aiming to accommodate a wide variety of languages with different semantics. This broad scope can sometimes lead to compromises when it comes to optimizing for specific language features or use c…

OpenJDK's new GC doesn't require STW pauses, the JDK offers preemptive scheduling for millions of threads as well as supervision trees -- although, to be fair, these are recent changes that have, at least in part, been inspired by Erlang. All that is on top of one of the world's most capable compilers. I have long admired Erlang and its passionate community as well as how much they've been able to accomplish (and, as…

To be a competitor, to be fair, implies there's competition. ¯\_(ツ)_/¯.

There's no world, where I'd allow for some future developer to write some Java on the same VM as my Erlang/Elixir code and risk the entire VM crashing.

JVM and Erlang's VM cater to different needs and programming paradigms. While they might share some features or learn from each other's innovations, they are not direct competitors but rather address unique use cases and development requirements.

People who want Erlang are going to reach for Erlang/OTP. People who want Scala/Akka/Java-monolith will leverage the JVM.

Replatforming, doesn't happen often.

No one is hopping from one platform for the other.

Re: Erlang/OTP: Garbage Collector

#58

Post by pron »

weatherlight wrote: post #57
pron wrote: post #53

Earlier quoted context omitted.

OpenJDK's new GC doesn't require STW pauses, the JDK offers preemptive scheduling for millions of threads as well as supervision trees -- although, to be fair, these are recent changes that have, at least in part, been inspired by Erlang. All that is on top of one of the world's most capable compilers. I have long admired Erlang and its passionate community as well as how much they've been able to accomplish (and, as…

To be a competitor, to be fair, implies there's competition. ¯\_(ツ)_/¯. There's no world, where I'd allow for some future developer to write some Java on the same VM as my Erlang/Elixir code and risk the entire VM crashing. JVM and Erlang's VM cater to different needs and programming paradigms. While they might share some features or learn from each other's innovations, they are not direct competitors but rather addr…

What do you mean by "the entire VM crashing"? The JVM is no more susceptible to crashes than BEAM.

BTW, my point is that can now be a very good platform for Erlang/OTP. Its performance will allow Erlang/Elixir programs to reduce their reliance on native code and to handle higher loads.

Re: Erlang/OTP: Garbage Collector

#59

Post by pron »

omginternets wrote: post #55
pron wrote: post #41

Earlier quoted context omitted.

The JVM has a selection of four generational GCs. Two of them are the most sophisticated GCs available anywhere. It's not a matter of some unique brilliance. Java is simply in such high demand that it has the sufficient resources to have state of the art optimising compilers and GCs.

Really? I had no idea. Can you suggest further reading?

https://docs.oracle.com/en/java/javase/20/gctuning/available...

https://youtu.be/OhPGN2Av44E

https://youtu.be/bLJJ3CY1aE8

Re: Erlang/OTP: Garbage Collector

#60

Post by weatherlight »

pron wrote: post #58
weatherlight wrote: post #57

Earlier quoted context omitted.

To be a competitor, to be fair, implies there's competition. ¯\_(ツ)_/¯. There's no world, where I'd allow for some future developer to write some Java on the same VM as my Erlang/Elixir code and risk the entire VM crashing. JVM and Erlang's VM cater to different needs and programming paradigms. While they might share some features or learn from each other's innovations, they are not direct competitors but rather addr…

What do you mean by "the entire VM crashing"? The JVM is no more susceptible to crashes than BEAM. BTW, my point is that can now be a very good platform for Erlang/OTP. Its performance will allow Erlang/Elixir programs to reduce their reliance on native code and to handle higher loads.

The JVM has 9 9s of reliability? Citation needed please.
Post reply on HN