Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is really cool and awesome, but after seeing the slow pace of JVM development over the last 6 years I really despair of doing major systems/database work in Java. It just feels like we are 10+ years ahead of where the VM is at.


> the slow pace of JVM development

Just in the past couple of years we've had a terrific new GC and the most powerful profiler I've ever seen (Java Flight Recorder) added to the JVM (the latter, unfortunately, not to OpenJDK yet). In a year, we'll have modules, JIT caching/AOT (possibly) and runtime control over JIT optimizations[1]. Work is already underway for atomic value types, classdynamic, a new FFI layer, and a next-gen, fully programmable JIT (Graal). Many of those enhancements are not only ahead of other production quality offerings, but truly state of the art if not groundbreaking. Even when I look hard I can't find another runtime that's less than 5+ years behind (and that's being generous).

[1]: http://openjdk.java.net/jeps/165


> we've had a terrific new GC

I assume you're referring to G1. AFAIK the first paper on G1 was published in 2004 when they already had working code — in the past couple of years it has merely stopped crashing on a regular basis. I remember times during JDK 8 development when they would fix one or two crashing bugs every week. In addition it has a 200ms stop-the-world pause that you can't get around (you can try to lower it but not into the 10ms area).

> and the most powerful profiler I've ever seen

jfr has been in JRockit for a long time. It took them four years to port it to Oracle JDK. I doubt it will ever be part of OpenJDK and assume you'll always need an Oracle Java support license if you want to run it in production. I dare you to get a quote for an Oracle Java support license.


What's your point? Are those technologies less groundbreaking or not years ahead of anyone else because they've been developed for years?

My experience with G1 has been a higher CPU consumption overall, but a very significant reduction in worst-case STW pause times. It works especially well for "session scope" objects: objects that are born together and die together, but may live for a relatively long time (seconds to minutes). I am not aware of any other runtime with GCs that even come close to the JVM's.

I am also not aware of any other profiler with such depth of reporting and such low overhead as JFR.

The work on Graal will continue for years, but when it is ready, it will be way ahead of the curve.

Innovation in the JVM is vibrant, and we're getting new, extremely powerful features at a good pace. The fact that each of those features takes years to implement well only proves the emphasis on big advancements (although minor advancements, like the JIT control feature in Java 9, are also made regularly).


> What's your point?

JVM development is slow. Things take years to a decade. If we want to have a GC that's better than G1 a decade from now we have to start now. G1 does not have an order of magnitude improvement in stw pauses in it. It may be good (or acceptable depending on where you stand) today but a decade from now we need something better.

The best features in the world are useless if you can't use them because of prohibitive licensing cost.


If you mean development latency, then you're right (throughput is quite high). And there are people working on next-gen GCs and next-gen JITs already.


How do you define "major"? By "10+ years ahead", are you referring to techniques for addressing very large datasets in memory?


This should change with Java 10. Project Jigsaw looks to be a pretty major change to the way the JVM will work scaling from very small to very big. Remains to be seen how well it pans out.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: