Optimising for Concurrency: Comparing the BEAM and JVM virtual machines • Hacker News Board

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#101

Post by eggsnbacon1 » Thu, May 14, 2020, 9:22 PM UTC

mrkeen wrote: post #100

eggsnbacon1 wrote: post #89

Earlier quoted context omitted.

Java does not allow one thread to kill another due to its shared memory concurrency model. It actually used to, but this feature was removed because it caused so many deadlocks. The reason is that killing threads won't always release monitors and locks. Lack of the feature is intentional. You can get a lot better nonblocking support with third party libraries. Like RxJS in javascript, RxJava is almost a requirement w…

> Java does not allow one thread to kill another due to its shared memory concurrency model. The reason is that killing threads won't always release monitors and locks. I can't follow the reasoning here. To refute it, you'd only need to show a language with shared memory and futures with cancel(), right? Aside from that, a second shortcoming isn't a good excuse for the first. > You can get a lot better nonblocking su…

Maybe I muddled my words on this. Java supports "requesting" thread cancellation, but its not safe to forcibly kill OS threads in any language I know of. For the same reason you can't in Java, finalizers won't run. This includes C and C# among others that use OS threads. https://stackoverflow.com/questions/13285375/how-to-kill-a-r... https://stackoverflow.com/questions/1327102/how-to-kill-a-th...

Notably C lets you do it with the big warning that it can crash everything. C# made the same decision as Java and doesn't allow it.

Java and pretty much all OS thread-using languages DO allow you to end threads by nicely asking them to stop. This is not the same as forcing them to. In all cases, if a thread is stuck in an infinite loop or a blocking call, it probably won't cancel if you ask it to. It depends on whether the thread is written to handle cancellation properly.

This is also a limitation of some languages with fibers, including Erlang. You can't force a thread thats stuck in certain states to stop running in Erlang even though it uses fibers. Some languages with fibers do allow it though.

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#102

Post by eggsnbacon1 » Thu, May 14, 2020, 9:29 PM UTC

Skinney wrote: post #90

eggsnbacon1 wrote: post #82

Earlier quoted context omitted.

Different strokes I guess. Erlang's model with fibers and message passing sounds close to Golang. Java has decent support for immutable objects with immutable collections, Lombok, the FreeBuilder library, both build-time code generators, and Java 14 record types. Automatic passing between machines is unique to Erlang Per process GC isn't anything like Java does, but the new GC's are probably fast enough that it doesn…

Sounds about right :) Just wanted to touch on one point. Golang also has shared memory, even though it encourages sharing by communicating. In Erlang you don't have a choice. Golang also doesn't have something like supervision trees (threads that die and restart together). So in practice golang and erlang concurrency is very different.

Interesting, so Golang channels are basically a hybrid between the two approaches.

I envy Rust and its borrow checker. Its a pain to get used to, but enables "shared when you say it is" concurrency model with no overhead. No message passing overhead, optional but safe mutability, no data corruption possibility, zero copy basically everywhere

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#103

Post by eggsnbacon1 » Thu, May 14, 2020, 9:36 PM UTC

kimi wrote: post #93

eggsnbacon1 wrote: post #83

Earlier quoted context omitted.

I have actually heard the same about Quasar so I have avoided using it. It hacks up the bytecode so evil bugs appear common based on my glances at issue tracker. Why didn't you use Kotlin coroutines? My understanding is that they achieve the same as Quasar without the insanity. You may also want to look at Vert.X. Its evolved into a lot more than a REST framework. It uses thread-per-core and nonblocking to achieve hi…

You may also look at Kotlin coroutines in VertX, that we are using and seem to work just fine.

I have been looking at this for an upcoming project where we need to handle a ton of persistent HTTP clients. Regular Vert.X is "fine" but TBH having all the callbacks sucks. My only reservation to using Kotlin is IDE support. I know its great in IntelliJ but licenses are expensive and I don't want to advocate something that ties us to a single IDE. Lots of our guys use Eclipse and VSCode.

I know there's plugins for Kotlin support in other IDE's, have you used them and if so are they any good?

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#104

Post by irq-1 » Thu, May 14, 2020, 10:21 PM UTC

hinkley wrote: post #37

di4na wrote: post #35

Earlier quoted context omitted.

I am not sure i understand the problem you are trying to find information about. Maybe explain it a little bit more ? or go ask for it in the elixir forum, people can try to be your librarians there

To an outsider, it seems like the BEAM documentation [and particularly, videos] go out of their way to discuss how process management and IPC communication works and how certain classes of data are managed. They talk about what makes the BEAM the BEAM to exclusion of all other concerns. Prior to finding this document ( http://www.cs-lab.org/historical_beam_instruction_set.html ) I had no idea whether you could actual…

> [and particularly, videos] go out of their way to discuss how process management and IPC communication works

After watching a bunch of videos on BEAM/erlang/elixir I came to the conclusion that it isn't a platform for computation, it's a platform for communication. The best video (by far) was The Soul of Erlang and Elixir • Saša Jurić https://www.youtube.com/watch?v=JvBT4XBdoUE

Two shallow benchmarks:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://www.techempower.com/benchmarks/ (phoenix is at 175)

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#105

Post by toast0 » Fri, May 15, 2020, 1:50 AM UTC

conradfr wrote: post #77

haspok wrote: post #74

Earlier quoted context omitted.

Don't forget ZIO (and other Cats Effect based libraries) which is the new kid on the block, and has it's own take on fibers and concurrent programming. The biggest problem with Erlang is that hardly anything out there needs this level of concurrency and robustness in a single system - in the new world of microservices and serverless architectures there are other ways to cope with scaling. This is the main selling poi…

Yes, that's a problem, you can't be the only one responsible for a core part of the stack. I did an interview at a major streaming company and one critical part was written in Erlang. It has been working great but the guy who wrote it had left for some time and nobody knew Erlang there, so they would have to rewrite it if an update was needed.

Or, someone could take a week to learn Erlang and make whatever change is needed. You won't be an Erlang expert in a week, but it's a pretty small language, so editing existing code isn't that hard. And that existing code can't be that bad, since it's still working.

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#106

Post by toast0 » Fri, May 15, 2020, 1:55 AM UTC

eggsnbacon1 wrote: post #101

mrkeen wrote: post #100

Earlier quoted context omitted.

> Java does not allow one thread to kill another due to its shared memory concurrency model. The reason is that killing threads won't always release monitors and locks. I can't follow the reasoning here. To refute it, you'd only need to show a language with shared memory and futures with cancel(), right? Aside from that, a second shortcoming isn't a good excuse for the first. > You can get a lot better nonblocking su…

Maybe I muddled my words on this. Java supports "requesting" thread cancellation, but its not safe to forcibly kill OS threads in any language I know of. For the same reason you can't in Java, finalizers won't run. This includes C and C# among others that use OS threads. https://stackoverflow.com/questions/13285375/how-to-kill-a-r... https://stackoverflow.com/questions/1327102/how-to-kill-a-th... Notably C lets you d…

What conditions do you need to get an Erlang process that you can't kill? Brutal kill, or load the executing module twice always worked for me (except for a couple deadlock bugs my company added to our locally patched BEAM)

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#107

Post by lostcolony » Fri, May 15, 2020, 2:14 AM UTC

thu2111 wrote: post #99

lostcolony wrote: post #45

Earlier quoted context omitted.

The article mentions "The JVM allows you to change the code while the program is running." However, that's not quite the same thing. The JVM allows you to change instructions, but not -data-. That is, in between versions you change what data a class contains, there is no way to change it out from the running instance. The JVM either has one version of the bytecode loaded, or the other; it has no concept of transition…

You can do that on the JVM too, just use separate classloaders and let the new objects reflect over the old to transition data across. It's not widely done though, for sure.

How do you move data? That Foo object that previously referenced both a Bar and a Baz, but you refactored it so now the Bar, not the Foo, has the reference to the Baz? Or where you changed the type of Baz from Gleep to Glorp?

Erlang, due to how actors encapsulate state, and dynamic typing, allows you to do those things pretty trivially.

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#108

Post by anko » Fri, May 15, 2020, 2:55 AM UTC

haspok wrote: post #74

eggsnbacon1 wrote: post #32

the author leaves out Kotlin which adds support for coroutines on the language level and still compiles to java bytecode. These are not classic continuations because they cannot be cancelled, but they're still very useful and true fibers. There's also the Quasar library that adds fiber support to existing Java projects, but its mostly unmaintained since the maintainers were pulled in to work on Project Loom. Then the…

Don't forget ZIO (and other Cats Effect based libraries) which is the new kid on the block, and has it's own take on fibers and concurrent programming. The biggest problem with Erlang is that hardly anything out there needs this level of concurrency and robustness in a single system - in the new world of microservices and serverless architectures there are other ways to cope with scaling. This is the main selling poi…

> The biggest problem with Erlang is that hardly anything out there needs this level of concurrency and robustness in a single system - in the new world of microservices and serverless architectures there are other ways to cope with scaling.

I wondered about this myself before I started using Elixir. In practice, it turns out when it's cheap to make things concurrent more services take advantage of this feature.

Tests and the elixir compiler are extremely fast because of this, and it makes the whole development experience better.

Because the primitives are so simple, people experiment more which makes better software. Nobody would come up with phoenix live view for Play framework in their spare time because play framework is so overly complicated.

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#109

Post by thu2111 » Fri, May 15, 2020, 10:00 AM UTC

lostcolony wrote: post #107

thu2111 wrote: post #99

Earlier quoted context omitted.

You can do that on the JVM too, just use separate classloaders and let the new objects reflect over the old to transition data across. It's not widely done though, for sure.

How do you move data? That Foo object that previously referenced both a Bar and a Baz, but you refactored it so now the Bar, not the Foo, has the reference to the Baz? Or where you changed the type of Baz from Gleep to Glorp? Erlang, due to how actors encapsulate state, and dynamic typing, allows you to do those things pretty trivially.

There are frameworks that support this kind of evolution, e.g. Kryo can do graph->graph transformations without intermediate serialisation I believe. Or you could write it by hand. If the static typing gets in the way you can always just use a scripting language to do it, many run on the JVM.

Re: Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

#110

Post by mrkeen » Fri, May 15, 2020, 5:53 PM UTC

eggsnbacon1 wrote: post #101

mrkeen wrote: post #100

Earlier quoted context omitted.

> Java does not allow one thread to kill another due to its shared memory concurrency model. The reason is that killing threads won't always release monitors and locks. I can't follow the reasoning here. To refute it, you'd only need to show a language with shared memory and futures with cancel(), right? Aside from that, a second shortcoming isn't a good excuse for the first. > You can get a lot better nonblocking su…

Maybe I muddled my words on this. Java supports "requesting" thread cancellation, but its not safe to forcibly kill OS threads in any language I know of. For the same reason you can't in Java, finalizers won't run. This includes C and C# among others that use OS threads. https://stackoverflow.com/questions/13285375/how-to-kill-a-r... https://stackoverflow.com/questions/1327102/how-to-kill-a-th... Notably C lets you d…

> Maybe I muddled my words on this.

Not at all. Thanks for your patience.

You've laid out really good arguments as to why Java Threads cannot be cancelled, and suggested that userspace threads -- which I (perhaps mistakenly) interpreted as CompletableFutures -- should be able to be cancelled.

But the thing is, I can cancel (request) Java Threads. And I cannot cancel CompletableFutures.

From my original comment:

> But CFs lack the functionality of Threads. A CF can't decide to sleep for a while, nor can it be cancelled.