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

Optimising for Concurrency: Comparing the BEAM and JVM virtual machines

erlang-solutions.com

Post reply on HN
Print view View original

21–30 of 114 posts

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

#21

Post by shawnz »

orestis wrote: post #18
brightball wrote: post #15

Earlier quoted context omitted.

Do you have a reference on that? I want to make sure you're talking about the same thing.

Clojure does hot code reloading as a built in. You essentially send code to a running system and you change it. It’s enabled by a dynamic class loader. I wouldn’t say it’s common outside of Clojure though, the whole language and ecosystem is built around this concept. To be clear: JVM enables the feature, so “technically” JVM allows hot code reload. Not sure how useful this is in practice for non-Clojure JVM users.

Eclipse, IntelliJ and Netbeans all support it out of the box for Java code.

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

#23

Post by mrkeen »

Traubenfuchs wrote: post #9

> Programming with concurrency primitives is a difficult task because of the challenges created by its shared memory model. I never understood this often repeated point. As junior / mid-level developer I had the privilege to run self written .jar files on government scale systems with more than 50 cores. I used Java thread pools and concurrent data structures to do heavy cross thread caching. It was all pretty simple…

> When is concurrency in Java ever hard?

Potentially-racey stuff:

* Synchronized primitives don't compose. You can safely `synchronized get(...)` and safely `synchronized put(...)`. But their composition put(get(...)+1) isn't synchronized. And it's hard to mentally revisit it at the end of the day: if you have a class with some methods marked synchronized, nothing will tell whether you've synchronized the right methods. You just have to think it through again and hope you reach the same conclusions as before.

Other (non-racey) stuff:

* Threads are heavy, CompletableFutures are light. But CFs lack the functionality of Threads. A CF can't decide to sleep for a while, nor can it be cancelled. (As an aside, BEAM threads are super light).

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

#24

Post by kasperni »

brightball wrote: post #15
shawnz wrote: post #11

The JVM supports hot code loading, although this article seems to imply only BEAM supports it.

Do you have a reference on that? I want to make sure you're talking about the same thing.

java.lang.invoke.MutableCallSite supports linking one particular MethodHandle at a time which the VM will optimize for. Then you can use MutableCallSite::setTarget with another MethodHandle which will cause recompilation of affected paths.

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

#25

Post by discreteevent »

mrkeen wrote: post #23
Traubenfuchs wrote: post #9

> Programming with concurrency primitives is a difficult task because of the challenges created by its shared memory model. I never understood this often repeated point. As junior / mid-level developer I had the privilege to run self written .jar files on government scale systems with more than 50 cores. I used Java thread pools and concurrent data structures to do heavy cross thread caching. It was all pretty simple…

> When is concurrency in Java ever hard? Potentially-racey stuff: * Synchronized primitives don't compose. You can safely `synchronized get(...)` and safely `synchronized put(...)`. But their composition put(get(...)+1) isn't synchronized. And it's hard to mentally revisit it at the end of the day: if you have a class with some methods marked synchronized, nothing will tell whether you've synchronized the right metho…

Java has a large set of higher level abstractions for concurrency. You don't have to use low level locks but you can. (And that's just Java, there's also Scala, clojure ...)

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

#26

Post by netrikare »

Traubenfuchs wrote: post #9

> Programming with concurrency primitives is a difficult task because of the challenges created by its shared memory model. I never understood this often repeated point. As junior / mid-level developer I had the privilege to run self written .jar files on government scale systems with more than 50 cores. I used Java thread pools and concurrent data structures to do heavy cross thread caching. It was all pretty simple…

>When is concurrency in Java ever hard+?

Take a look at dated, but still relevant book by Brian Goetz - Java Concurrency in Practice - many problems are illustrated with a code section.

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

#27

Post by eggsnbacon1 »

brightball wrote: post #15
shawnz wrote: post #11

The JVM supports hot code loading, although this article seems to imply only BEAM supports it.

Do you have a reference on that? I want to make sure you're talking about the same thing.

generating code during runtime is rather common in Java frameworks. Most really popular frameworks use it. Spring for AOP and Hibernate for "bytecode enhancement". There's a number of libraries, like CGLIB and ByteBuddy designed explicitly to make this easy.

There are limits to how much you can change in existing loaded class code, but if you are just loading up new dynamically generated code you can do pretty much anything.

Its a big reason why some of these Java frameworks are so fast. They can generate highly optimized code on the fly, load it, and have it running alongside the existing app code within a few hundred milliseconds. And the Java JIT will optimize it as if the code was there the whole time.

This makes performance optimizations easy that would be impossible in AOT languages like Go, C, C++, Rust, etc

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

#29

Post by carapace »

Traubenfuchs wrote: post #9

> Programming with concurrency primitives is a difficult task because of the challenges created by its shared memory model. I never understood this often repeated point. As junior / mid-level developer I had the privilege to run self written .jar files on government scale systems with more than 50 cores. I used Java thread pools and concurrent data structures to do heavy cross thread caching. It was all pretty simple…

> Were the types of problems/challenges I was solving too simple?

Without more information this is the likely scenario, going by my own experience.

BTW, if it turns out you are a concurrent programming genius please write about it, eh? (Like a blog or book or something.)

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

#30

Post by throwaway894345 »

discreteevent wrote: post #25
mrkeen wrote: post #23

Earlier quoted context omitted.

> When is concurrency in Java ever hard? Potentially-racey stuff: * Synchronized primitives don't compose. You can safely `synchronized get(...)` and safely `synchronized put(...)`. But their composition put(get(...)+1) isn't synchronized. And it's hard to mentally revisit it at the end of the day: if you have a class with some methods marked synchronized, nothing will tell whether you've synchronized the right metho…

Java has a large set of higher level abstractions for concurrency. You don't have to use low level locks but you can. (And that's just Java, there's also Scala, clojure ...)

I'm pretty firmly in the "shared memory parallelism is a Good Thing" camp, but the counter argument to your point is that having a larger set of concurrency abstractions is a Bad Thing in that any particular piece of code has to consider all of the different permutations. In a shared-nothing world, there's a lot less to worry about (except occasionally performance).
Post reply on HN