Michal Cierniak – In my opinion modularity will not bring significant performance wins.Â I agree, but that’s not the point.Â Java needs modularity and ahead of time compilation so that it can start fast and share memory between processes, otherwise Steve Jobs has a point.

I don’t hear many folks, that run Java applications, complaining that Java’s performance is poor once the application is running.Â However they do complain that the applications take a long time to start and that when running many Java applications LOTs of memory is consumed.Â I work for a company that makes use of three significant java applications.Â No one would claim that they start fast, but my biggest complaint is that these three applications, that are all built on the same code base, share no memory at runtime, none, zip, nadda, nothing.

It’s like we have gone back 40 years in computing history.Â There used to be a time that programs didn’t share any memory but that went away with the introduction of dynamic linking and shared libraries. Most programs use DLLs (Windows) and Shared Objects (Unix) to ensure fast startup and efficient memory sharing and all of this is managed by the OS.Â If two concurrently running programs both decide to use the same spell checking library then that library is memory mapped into the address space of the two programs by the operating system i.e. there is only one copy resident in memory. In java this is not true, there is a unique copy resident in each address space.

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.

It’s also not like the problem of memory sharing and startup isn’t well understood in the Java world. Sun produced a paper 5 years ago trying some crazy dynamic memory sharing thing and followed that with a paper the very next year that deduced instead that shared libraries were the way to go as the first "dynamic" approach "required complex engineering" while using shared libraries was "simpler" and "relies on existing software and OS mechanisms".

However the opportunity to produce shared libraries from Java code has not been seized upon (IMO it’s too hard with custom classloaders) and there have been many other attempts at sharing memory in Java, non of which have yet proven successful. C# and CLIs, which were developed with the benefit of experience with JVMs, made efficient AOT a priority and reap the benefits of faster startup and better sharing.

So why not take the opportunity that JSR294 is providing and level the playing field with CLIs by using it to provide efficient AOT for Java that in turn allows Java code to compile to shared libraries? As a result Java will start faster and share memory between processes.Â Without this CLIs will maintain a significant advantage and they have enough of those already.