JVM Internals (2013) • Hacker News Board

Re: JVM Internals (2013)

#21

Post by pron » Sun, Apr 19, 2015, 3:52 PM UTC

mike_hearn wrote: post #20

ed_blackburn wrote: post #3

I'm a CLR man myself. Just the path my career has taken me really. Does anyone know if there are equivalent documents for CLR or CLR Core? I don't see LLVM, JVM or the CLR going anywhere. They'll evolve, get smaller, reach more devices and platforms etc but personally I'd like to appreciate the how and the why better. It'd be useful to know if there are any reasons why I may pick one over the other in certain circums…

My understanding, which may be wrong as I know a lot more about the HotSpot and ART JVMs than CoreCLR, is that the differences boil down to: • CoreCLR has support for some static language features that C# has but Java lacks, like ability to embed unsafe code easily. In theory you can do that in Java too using sun.misc.Unsafe but nobody actually does. • HotSpot has historically had a tighter and more focused approach…

> In theory you can do that in Java too using sun.misc.Unsafe but nobody actually does.

You wouldn't believe how many libraries use sun.misc.Unsafe, which is why it is being considered as a public API in Java 9 (this is necessary because access to it will be restricted by the new module system). It's used by people building their own concurrency primitives (it offers direct access to memory fences), as well as by people doing low-latency, low-garbage processing (very common in the UK financial trading industry).

> .NET can do ahead of time compilation when an app is installed, whereas HotSpot cannot

Right, but all realtime JVMs offer AOT compilation (it's the usual tradeoff: slower code but more predictable), and even HotSpot may offer either AOT (less likely) or JIT caching (more likely) in Java 9.

Re: JVM Internals (2013)

#22

Post by lambdaelite » Sun, Apr 19, 2015, 4:11 PM UTC

pron wrote: post #18

lambdaelite wrote: post #16

Earlier quoted context omitted.

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.

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…

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?

Re: JVM Internals (2013)

#23

Post by pron » Sun, Apr 19, 2015, 4:21 PM UTC

lambdaelite wrote: post #22

pron wrote: post #18

Earlier quoted context omitted.

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…

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 experi…

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

Re: JVM Internals (2013)

#24

Post by tokenizerrr » Sun, Apr 19, 2015, 5:52 PM UTC

pron wrote: post #15

tokenizerrr wrote: post #7

Earlier quoted context omitted.

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

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.

Re: JVM Internals (2013)

#25

Post by btdollar » Sun, Apr 19, 2015, 7:28 PM UTC

pron wrote: post #6

ed_blackburn wrote: post #3

I'm a CLR man myself. Just the path my career has taken me really. Does anyone know if there are equivalent documents for CLR or CLR Core? I don't see LLVM, JVM or the CLR going anywhere. They'll evolve, get smaller, reach more devices and platforms etc but personally I'd like to appreciate the how and the why better. It'd be useful to know if there are any reasons why I may pick one over the other in certain circums…

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…

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.

Re: JVM Internals (2013)

#26

Post by pron » Sun, Apr 19, 2015, 7:29 PM UTC

tokenizerrr wrote: post #24

pron wrote: post #15

Earlier quoted context omitted.

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.