Hacker News new | ask | show | jobs
by pron 4077 days ago
Well, LLVM is something else altogether, as it doesn't try to abstract away the OS, while the JVM does[1]. As to the JVM, well, first of all, there is no "the JVM". There are many JVMs by many vendors, and many types of JVMs (from smart-cards, through various embedded devices, and all the way to desktops, servers and mainframes). Some of the most interesting -- and most important -- ones are made by companies you've probably never heard of, like Aicas and Atego that make hard realtime JVMs for use in avionics, medical devices and other safety-critical systems. The best-known JVMs are HotSpot, OpenJDK's JVM (which serves as the basis for Oracle and Azul's JVMs) and J9, IBM's JVM. When many people say "the JVM" they mean the SE (i.e. "standard edition") of HotSpot.

While HotSpot and the CLR are more similar -- at least in their goals -- than different, and each is ahead of the other in some respects and behind in others, I'd say that the most interesting features of HotSpot are its JIT and GCs (it comes with a few) that are years ahead of anything else used in any other environment in the industry (well, except Azul that sells a modified HotSpot with a "pauseless" GC that never pauses the application for more than a few microseconds). In my opinion, the most exciting development regarding HotSpot is the work being done on HotSpot's next generation optimizing JIT called Graal, that comes with an a complementary language toolkit called Truffle[2]. It pushes the envelopes further with regards to HotSpot's defining feature -- speculative optimization and deoptimization -- and lets the user (if they wish) control the code generation through a clever API.

Another important feature of any compliant SE JVM is bytecode manipulation. It allows modifying libraries after they've been compiled -- either on disk or during the class loading process. One use is dependency namespacing, aka shadowing (if your program depends on libraries A and B, and they each depend on different, incompatible versions of library C, shadowing can hide the two versions of C from each other). But one of the coolest things is the ability to transform (and de-transform) bytecode of running classes (to inject, say, tracing).

Since HotSpot is part of OpenJDK, all work on it (including Graal and Truffle) is open-source (and has been for a few years now). The OpenJDK as a whole is probably the world's second largest open-source project (in terms of contributors), after the Linux kernel. The main contributors are, of course, Oracle and IBM (the latter to a much lesser degree), but also Google, Intel, Apple, Twitter and many more.

[1]: https://www.youtube.com/watch?v=uL2D3qzHtqY

[2]: https://wiki.openjdk.java.net/display/Graal/Publications+and...

4 comments

> When many people say "the JVM" they mean the SE (i.e. "standard edition") of HotSpot

This changed in Java 7. OpenJDK is now the reference implementation, and thus "the JVM"

The fallacy is that those of us that deal with commercial JVMs have more to choose from than "the JVM".
OpenJDK is a lot more than just the JVM (it's also the runtime libraries). Open JDK's JVM is named HotSpot.
I think the only JVM named HotSpot is the one distributed by Oracle.
They are one and the same. Oracle's JVM is the OpenJDK's JVM, slightly modified (they mostly add monitoring capabilities that were part of the JRockit JVM), and Oracle's JDK (which contains the JVM) is OpenJDK with some minor additions.
Thank you for taking the time to explain. In the past couple of years I've noticed businesses are less beholden to one specific platform. Heterogeneous environments are becoming the norm. As a .NET consultant I've noticed a pattern of node websites, CLR (C#) domains and the JVM rich ecosystem offering systems like Elastic Search or Storm. Knitted together with something like Rest APIs and Rabbit.

I really want to appreciate more of the wider ecosystem and the tech that underpins it. I don't see the point in implementing what is proven on the JVM on the CLR.

Concentrate on the businesses business (the core domain), not plumbing. In short learning more about these techs in paramount.

Do you have, or know anyone, that has experience using a JVM in a safety critical application? I'm trying to decide if I want to use it in a medical device, or go the more conventional MISRA-C on QNX route.
The most mission critical one is probably the Aegis Ballistic Missile Defense System.

Here's Lockheed Martin announcing that they chose a (propriety) JVM to run "several critical subsystems" of the Aegis system in 2006[0].

Here's them announcing said project passing operational trials fours years later[1]. Surprisingly fast for a military project.

[0] http://www.atego.com/pressreleases/pressitem/lockheed-martin...

[1] http://www.atego.com/pressreleases/pressitem/aonix-perc-ultr...

I used a hard realtime JVM for a safety-critical missile-defense related application, but that was almost ten years ago. The JVMs to consider are IBM's WebSphere Real Time[1], Aicas JamaicaVM[2] (their front page shows examples of use in medical devices) and Atego (formerly Aonix) Perc[3]. Both Aicas and Atego focus on the embedded market (don't know about WebSphere RT).

See here for some background and some related links (http://www.javaworld.com/article/2906981/java-app-dev/little...). There's recently been a lot of activity around RTSJ 2.0 (real-time specification for Java)[4], JSR-282, led by Aicas, and JSR-302[5] -- also led by Aicas -- which is built on top of RTSJ and meant to support DO-178B certified, safety-critical applications. I see that JSR-302 is marked inactive[6], which means it hasn't had a milestone in the past year, but I think that the relevant JVMs already implement it (or something similar), even if it hasn't been ratified as a standard.

I can tell you that for us, at least 10 years ago, it was a remarkable success, and saved us a lot of time vs. developing in C or Ada, but that was for code running on large servers. I haven't had experience with RTSJ on embedded devices. Many others have, but I doubt they read HN.

You probably want to keep DSP in C, but for everything else Java may save you a lot of time and money.

[1]: http://www-03.ibm.com/software/products/en/real-time

[2]: https://www.aicas.com/

[3]: http://www.atego.com/products/atego-perc/

[4]: https://www.aicas.com/cms/en/rtsj

[5]: http://download.oracle.com/otn-pub/jcp/safety_critical-0_94-...

[6]: https://jcp.org/en/jsr/detail?id=302

Thanks so much for taking the time on a thoughtful response.

> I can tell you that for us, at least 10 years ago, it was a remarkable success, and saved us a lot of time vs. developing in C or Ada, but that was for code running on large servers.

To what do you attribute the time savings? I'm interested in using the JVM because I'm thinking I'll have an advantage in debugging over C. Would that be true, in your experience? Do you think that it was easier to develop using the JVM under your quality system than it would have been under C or Ada?

> I haven't had experience with RTSJ on embedded devices. Many others have, but I doubt they read HN.

Yeah... Do you know of a good mailing list or forum for embedded systems?

> To what do you attribute the time savings?

It's just much easier to produce correct code in Java than in C (or even Ada). The bigger and more complex the software -- the bigger the gains (it's easy to write simple/small programs in any language). We also used NASA's open-source Java PathFinder to verify parts of the code (there are model checkers for C, too, and others for Java). This paper (https://ti.arc.nasa.gov/m/groups/rse/papers/lindstrom-rtembe...) describes applying JPF to the realtime scheduling aspects of RTSJ (something we didn't do).

> Do you know of a good mailing list or forum for embedded systems?

Sadly, no, but others here might.

Thank you for reminding me of Graal. One of the most interesting projects I have ever seen, and I have just gotten a lot of free time to explore it.