4 ms·

Thanks for the link to the Doug Lea screencast/talk, very interesting so far. EDIT: Indeed it was a great talk, very informative! I came to the opposite conclu

by ehsanu1 13y ago

Thanks for the link to the Doug Lea screencast/talk, very interesting so far. EDIT: Indeed it was a great talk, very informative! I came to the opposite conclusion about layers of the system, though I'd say that it isn't the number of layers that's the problem, but the nature of them. From the talk, having the GC insert safepoints where threads can be stopped for a collection, and having the JIT inserting counters (resulting in memory contention) are two things in Java that caused for high-performance concurrency. Running on top of a VM causes similar issues. Though, clearly there are many other layers and unanticipated layer interactions, just laying in wait to mess you up regardless.

pron 13y ago
Well, he only mentions how these things make his life difficult, not how they make it easier. When you consider something, you must also consider the alternatives: a GC does insert safepoints on the one hand, but it makes lock-free data structures possible (or much, much easier) on the other. The JIT counters introduce contention before optimization kicks in, but then you get virtual method inlining, the mother of all optimizations, which you can't do without a JIT, certainly not when you want to support hot code loading. Those things are necessary for the class of programs Java SE is meant to support (long running, high-performance server-side applications); they're not ideal for device drivers, command line programs or fast-loading GUI apps, which Rust is designed to handle. Everything is a tradeoff.