Comments on: Worlds Apart – JVMs and CLIs

By: robubu : Unladen Swallow, a Hummer Hybrid?

robubu : Unladen Swallow, a Hummer Hybrid? — Wed, 21 Oct 2009 00:49:48 +0000

[...] the problems inherent in making any dynamic language go faster, namely type inference. I’ve blogged about this before for Java and the unladen swallow presentation does a good job of explaining all the pitfalls around [...]

By: robubu - the technical weblog of Rob Yates » Worlds Apart - Why Java needs ahead of time compilation and why C# has it

Wed, 02 May 2007 03:00:29 +0000

[...] So why can’t Java programs share memory given that shared libraries are a technology that’s been in widespread use for at least 25 years? It’s really for two reasons. The first is that up until this point there has really been no way to define a shared library in Java i.e. here’s a bunch of code and here is its external interface. JSR294 (modularity for Java) addresses this point. The second is that Java has no efficient AOT compilation and so unlike most other statically typed languages it can’t utilize the traditional OS functions to load and share its libraries. I have belabored this point in the other "Worlds Apart" posts here and here, pointing out that this is a key differentiation for CLI implementations such as .net or mono. Miguel (mono lead) also has an excellent post that provides a good overview of mono’s AOT support and the rationale behind it. JSR294 could be designed in such a way to provide for efficient AOT, and I belabor this point here. [...]

By: robubu - the technical weblog of Rob Yates » Worlds Apart - C# and Java

robubu - the technical weblog of Rob Yates » Worlds Apart - C# and Java — Fri, 27 Apr 2007 00:52:59 +0000

[...] Alex Buckley C# itself is no more or less designed for these analyses than Java. (in response to compilation approaches outlined in Worlds Apart – JVMs and CLIs). [...]

By: Patrick Wright

Patrick Wright — Fri, 20 Apr 2007 21:31:18 +0000

Rob–I believe that when you say “JVMs, on the other hand, use runtime knowledge to decide what to optimize” is only true for some JVMs, and is not required by the JVM spec. In fact, early on the approach was to have JIT-only, but the overhead of JIT’ing all code (even code which ran infrequently) plus other issues (all that compiled code needs to be cached, and the cache managed) meant that other approaches were tried. Mixed-mode, runtime-optimizing compilers, like Hotspot, are one alternative. But there are others–there are not only optimized JITs still being developed, but also AOT compilers (including gcj and Excelsior Jet)–unfortunately in many cases these are buried under IP protection so we don’t know exactly what they are doing. It is true that Sun’s Hotspot’s dynamic-optimization gets the most press because it’s turned out to lead to great performance, although it took a long time. But as with a market economy, where prices tend to stabilize, in the Java world I think it’s the case that performance of these various approaches are within spitting distance of each other. I certainly don’t think that the Java/CLR comparison can be made so easily. Best regards, Patrick

By: Pure Danger Tech » Blog Archive » Java 7 Roundup (Apr 18th)

Pure Danger Tech » Blog Archive » Java 7 Roundup (Apr 18th) — Thu, 19 Apr 2007 03:34:40 +0000

[...] Rob Yates had an interesting post this week on the difference between the JVM and CLI approach to compilation. Specifically, how does the CLI differ from having a static module system from the start as opposed to the JVM’s more open dynamic classloader system. Seems like the changes in JSR 294/277 might create a world where you could get the benefits of both. [...]

By: Alex Miller

Alex Miller — Thu, 19 Apr 2007 03:05:54 +0000

I believe the JSR 294 proposal (superpackages) specifies that a superpackage (presumably will be linked to a JSR 277 JAM) must be loaded by the same classloader. Or at least that’s my understanding from the strawman proposal. So, maybe that will become an option in Java 7.

By: Rob Yates

Rob Yates — Sat, 31 Mar 2007 01:59:50 +0000

Glyn, so for a module to be able to be AOT'd then as mentioned above classic analysis techniques need to be applicable to Java code. There are a few "features" in java that make this basically impossible to do. These are those features that allow code to alter the class hierarchy dynamically at runtime. Custom Classloaders and javaagents are two such examples (there may be others). The classloading rules would therefore need to be changed so that there is only ever one classloader per module. IKVM (java for CLI) has an approach close to what I think is needed.

By: Gastromancer

Gastromancer — Fri, 30 Mar 2007 20:32:13 +0000

Hmmm…. if Gosling were correct about the importance of hardware optimization, then wouldn’t we see source-code-only distros like gentoo getting significant traction? Wouldn’t you see Matlab recompiling itself on install?

It’s a very convenient explanation, that there’s lots of optimization you can do, last-minute. But it requires proof. And microbenchmarks aren’t proof.

By: Dominic Cooney

Dominic Cooney — Fri, 30 Mar 2007 13:58:33 +0000

Neil: Gosling is right about the different characteristics of different processors. .NET ahead-of-time compilation actually happens when the bytecode is put onto a particular machine (typically when software is installed), so the compilation can take advantage of the characteristics of the PC’s particular processor. Significant changes to the system cause the cache of native images to be invalidated, and then .NET falls back to runtime JITting.

By: Neil Bartlett

Neil Bartlett — Fri, 30 Mar 2007 11:01:03 +0000

Rob,

Interesting analysis, thanks.

One justifcation I heard for Java’s very late compilation and optimization of bytecode was described by James Gosling in a talk he gave (which I blogged about here: http://neilbartlett.name/blog/2007/03/15/an-evening-with-james-gosling). He said that there is substantial variation between individual processors even within the same line, i.e. the Pentium IV I have in my PC and the Pentium IV you have in your PC, although they share functional compatibility, have very different optimization characteristics. And of course both of them very different from from an AMD chip. Because the JVM compiles as late as possible, it can optimize for the “exact piece of silicon it’s running on” (his words). Whereas if you distribute native binaries then all you can do is optimize for the generic x86 architecture.

Now, I don’t know enough of the low-level details to know whether that’s a valid justification or a load of hot air. I just wanted to point out that there is at least a theoretical advantage in very late compilation, even if it doesn’t translate to a practical advantage.

Neil