3 ms·

Azul has made a JVM with predictable GC. http://www.azulsystems.com/technology/java-garbage-collection http://www.azulsystems.com/technology/java-garbage-colle

• cwzwarich 13y ago
  To run it on x86, you need a heavily modified Linux kernel. You also sacrifice about 30% or so of your throughput on the extra operations that allow for the dramatically reduced latency, which may not be acceptable for some people.
• jandrewrogers 13y ago
  I do not see how this solves the server software side of things. Most high performance server software (1) has precisely one process/thread per core and (2) takes complete control of its memory management. These behaviors have substantial performance benefits. A GC thread of any type will bleed performance, and that is ignoring the loss of performance from poor memory and cache efficiency that is inherent with GCs. High performance server code is one of those areas that highlights where GCs are inappropriate. I've written quite a few server engines in GC languages; you expect to see about half the performance of C/C++ as a rule of thumb. Most modern server software performance is significantly bound by memory bandwidth and latency. Introducing inefficiencies in this area tends to result in material degradation of software throughput. In fact, this is the only substantial advantage of C/C++; it can be efficient with memory access, caching, and utilization in a way that no GC language can be, and these are major contributing factors to performance.
  • cbsmith 13y ago
    The notion that poor memory cache efficiency is inherent with GC's is not terribly well founded. Copying collectors (like the one the HotSpot VM uses for Eden Space) tend to have great cache efficiency as compared to typical use of the C heap, where you can't relocate chunks of correlated memory together. Even mark-and-sweep collectors can do quite well for themselves. I'd actually say quite the opposite of what you are saying: in a server environment, you often care more about throughput and mean latency (as opposed to 99th %-ile latency), and GC can really do great there. What's nice is that GC allows you to have near zero cost heap allocations and amortizes the cost of cleanup. What tends to be the problem is a lot of languages with GC make it difficult to efficiently work with the systems's buffer cache, so you typically see problems with systems that do disk I/O with large amounts of data. I've written a LOT of C/C++ & JVM based servers. Particularly for large projects with a lot of independent moving parts and object lifecycles that are not tightly tied to sessions, the JVM based servers are remarkably competitive if they aren't disk IO bound. There's a reason why a lot of HFT firms use Java... C/C++ still kicks butt for tightly written servers with fairly fixed functions, and generally for anything that does tons of disk IO (though the Cassandra guys have, as an example, demonstrated one can do quite well if you take the time to get it right), and of course anything with unsigned arithmetic (seriously, when are we going to acknowledge that this was a bad idea?).
    • kevinnk 13y ago
      > The notion that poor memory cache efficiency is inherent with GC's is not terribly well founded. It may not be "inherent" to GC, but in practice every GC that I'm aware of has terrible cache efficiency compared to manual memory management. > Copying collectors (like the one the HotSpot VM uses for Eden Space) tend to have great cache efficiency as compared to typical use of the C heap False comparison. The real test is against high performance memory techniques (like memory pools, which are relatively easy and common in practice if you care at all about cache efficiency) not "typical use of the C heap." When you actually compare GC vs high performance manual memory management, manual memory management is significantly faster.
      • cbsmith 13y ago
        > False comparison. The real test is against high performance memory techniques (like memory pools, which are relatively easy and common in practice if you care at all about cache efficiency) not "typical use of the C heap." When you actually compare GC vs high performance manual memory management, manual memory management is significantly faster. That's not a false comparison. They represent about equal development effort (well, the GC version is likely still less effort). Sure, if you spend a ton of time optimizing your memory usage for your specific needs you will do better than a general purpose algorithm (though it is remarkable how often those solutions often implement their own forms of automatic memory management tuned for their needs). If it turns out that you couldn't do that, it'd be awfully hard to collect a paycheck (and in fact most programmers could not collect that paycheck). Of course, even that effort would not measure up as compared to an omniscient GC algorithm (and the paycheck for building that would be even bigger ;-). What is the point? GC's do well. When you really need to tune memory usage, you get in there and do the work, and you and do that in GC'd runtimes too. A good memory manager will, for common workloads, start you off in a better place and make the work of tuning easier. Certainly there are cases where it won't be so helpful, but that doesn't mean they are "bad" at memory cache efficiency.