3 ms·

You can always do better than GCed shared memory VM, especially in concurrent applications. And in general shared data structures always slow down concurrent ap

You can always do better than GCed shared memory VM, especially in concurrent applications. And in general shared data structures always slow down concurrent applications. There is no future for JVM in concurrency at this point. Even a toy VM/language designed for concurrency will be able to beat it.

pron 7y ago
No, but you can try if you think you can.
- zzzcpan 7y ago
  We are not in the dark ages anymore. Denying reality doesn't help anyone here. Shared memory is dead for concurrency, it can't be made neither fast, nor easy to use.
  - pron 7y ago
    I don't know what reality I'm denying. These post-dark-ages days Amazon, Apple, Google, Netflix and Twitter -- among many, many others -- are betting heavily on OpenJDK, with its shared heap GCs, for many/most of their big, concurrent backend applications.
    - zzzcpan 7y ago
      I though we were talking about engineering challenges, research, not bets execs of large companies make for very different reasons, mostly hiring reasons.
      - pron 7y ago
        Oh, sorry, I didn't realize you're a Google/Apple/Netflix/Amazon executive who's intimately familiar with their technical decisions. It's certainly true there is a lot of research on non-shared memory, but also a lot of research on shared memory. If non-shared has so decisively won, then not only the executives but also the researchers didn't get that memo. If and when non-shared "wins", the popular industry platforms will adjust as well.
        dang 7y ago
        Can you please review and follow the site guidelines? They include "Don't be snarky." Your comment would be just fine without the first sentence. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
      - marcinzm 7y ago
        >I though we were talking about engineering challenges, research, not bets execs of large companies make for very different reasons, mostly hiring reasons. Large companies don't pick technologies for hiring reasons, small companies do. Large tech companies can afford to train their engineers in whatever they use internally and have the money (and brand recognition) to not worry about needing technologies to entice candidates. They pick technologies to solve business problems.
  - wtetzner 7y ago
    If you're working with immutable data structures, then shared memory concurrency works very well.
jacques_chester 7y ago
> There is no future for JVM in concurrency at this point. Even a toy VM/language designed for concurrency will be able to beat it. I disagree. Java's concurrency features are extremely rich. Parallel stream are basically magic: I add .parallel() and pow, near-linear speedups. No channels, no select statements, no realising I messed up a mutex somewhere. It just works. Then there's reactive programming. The JVM can chew through truly absurd amounts of requests when a reactive approach is taken.
mcguire 7y ago
"Even a toy VM/language designed for concurrency will be able to beat it." Citation needed. The JVM has a lot of problems, mostly due to its concentration on Java and bytecode/JITting. Given those constraints, memory management isn't really one of them.

pron 7y ago

No, but you can try if you think you can.

zzzcpan 7y ago
We are not in the dark ages anymore. Denying reality doesn't help anyone here. Shared memory is dead for concurrency, it can't be made neither fast, nor easy to use.
- pron 7y ago
  I don't know what reality I'm denying. These post-dark-ages days Amazon, Apple, Google, Netflix and Twitter -- among many, many others -- are betting heavily on OpenJDK, with its shared heap GCs, for many/most of their big, concurrent backend applications.
  - zzzcpan 7y ago
    I though we were talking about engineering challenges, research, not bets execs of large companies make for very different reasons, mostly hiring reasons.
    - pron 7y ago
      Oh, sorry, I didn't realize you're a Google/Apple/Netflix/Amazon executive who's intimately familiar with their technical decisions. It's certainly true there is a lot of research on non-shared memory, but also a lot of research on shared memory. If non-shared has so decisively won, then not only the executives but also the researchers didn't get that memo. If and when non-shared "wins", the popular industry platforms will adjust as well.
      - dang 7y ago
        Can you please review and follow the site guidelines? They include "Don't be snarky." Your comment would be just fine without the first sentence. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - marcinzm 7y ago
      >I though we were talking about engineering challenges, research, not bets execs of large companies make for very different reasons, mostly hiring reasons. Large companies don't pick technologies for hiring reasons, small companies do. Large tech companies can afford to train their engineers in whatever they use internally and have the money (and brand recognition) to not worry about needing technologies to entice candidates. They pick technologies to solve business problems.
- wtetzner 7y ago
  If you're working with immutable data structures, then shared memory concurrency works very well.

jacques_chester 7y ago

> There is no future for JVM in concurrency at this point. Even a toy VM/language designed for concurrency will be able to beat it. I disagree. Java's concurrency features are extremely rich. Parallel stream are basically magic: I add .parallel() and pow, near-linear speedups. No channels, no select statements, no realising I messed up a mutex somewhere. It just works. Then there's reactive programming. The JVM can chew through truly absurd amounts of requests when a reactive approach is taken.

mcguire 7y ago

"Even a toy VM/language designed for concurrency will be able to beat it." Citation needed. The JVM has a lot of problems, mostly due to its concentration on Java and bytecode/JITting. Given those constraints, memory management isn't really one of them.