4 ms·

> 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 pa

> 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.

pron 12y ago
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).
- needusername 12y ago
  > 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.
  - pron 12y ago
    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.

pron 12y ago

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).

needusername 12y ago
> 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.
- pron 12y ago
  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.