Ahead of Time Compilation in Mono

by Miguel de Icaza

A few years ago we modified the Mono code generation engine from being merely a Just-in-Time compiler for managed code to be also a batch compiler that could be used to batch compile code in advance.

We call this batch compilation process "Ahead of Time Compilation" or AOT.

There are many reasons for supporting AOT compilation: reduced startup time, reduced overall memory usage and the possibility of running better optimized code.

This batch compilation is typically done by invoking the mono command with the --aot flag on a managed assembly, like this:

 $ mono --aot hello.exe
 $ ls -l hello.exe.*
 -rwxr-xr-x 1 miguel users  3584 2006-08-15 12:38 hello.exe
 -rwxr-xr-x 1 miguel users 10769 2006-08-17 00:05 hello.exe.so


The .exe file in the above listing contains the managed code in CIL format, while the hello.exe.so is an ELF file that contains the pre-compiled code.

Today, the .so file only contains the pre-compiled code but does not contain any of the additional metadata that is present on the .exe file. To run the application it is necessary to have the original assembly (.exe or .dll) around as it contains information that is not replicated on the executable.

To execute the code, you must still invoke Mono with the original parameters, for instance:

 $ mono hello.exe


The runtime will take care of probing whether there is a native pre-compiled image, and if the image is valid, it will use the pre-compiled code from the shared object instead of JITing the code as it goes.

As I mentioned before, there were an array of motivations for implementing AOT in Mono. Initially we hoped to reduced application startup time as the JIT had less work to do. In practice, the Mono JIT was fast enough that the JIT time was never much of an issue, even with the last batch of optimizations that were turned on in Mono 1.1.16, the startup speed is not even noticeable. In addition, there is a slight memory gain by not executing code in the JIT in the first place, so there was a small memory improvement as well.

Heavier optimizations that exist today, and heavier optimizations that we are developing will make the use of AOT more important, as those code generation optimizations are slower to have enabled by default on the Just-in-Time compilation stage.

This is what the original design of the AOT file format was designed to cope with: startup time.

In the last few months Zoltan has been working on adapting AOT for another task: overall memory reduction.

As developers start to run a handful of Mono applications on a desktop, we want to minimize the duplicated code in memory. To do this, we had to address a number of problems with the original AOT design.

The original AOT design had poor multi-process page sharing capabilities, as the JIT had to fix-up the mapped AOT code in memory. The native code was shared across multiple processes by using mmap() to map the native code into each process, but as the fix-ups were applied to the mapped code, the numbers of pages that could be shared across processes decreased.

The new design by Zoltan for the AOT generated code is very similar to the ELF shared libraries file format. It uses a couple of tables for data and code (Global Offset Table a slightly modified Program Linkage Table tuned for Mono compilation) which are the only pieces that are modified.

 $ mono --aot /mono/lib/mono/1.0/mscorlib.dll
 Mono Ahead of Time compiler - compiling assembly /mono/lib/mono/1.0/mscorlib.dll
 Code: 1632832 Info: 105844 Ex Info: 46601 Class Info: 39399 PLT: 4127 GOT: 55756
 Executing the native assembler: as /tmp/mono_aot_jiqD57 -o /tmp/mono_aot_jiqD57.o
 Executing the native linker: ld -shared -o /mono/lib/mono/1.0/mscorlib.dll.so 
 Compiled 11050 out of 11051 methods (99%)
 1 methods contain absolute addresses (0%)
 0 methods contain wrapper references (0%)
 0 methods contain lmf pointers (0%)
 0 methods have other problems (0%)
 Methods without GOT slots: 7322 (66%)
 Direct calls: 11350 (53%)
 GOT slot distribution:
         methodconst: 25
         switch: 167
         class: 2176
         field: 165
         vtable: 3241
         sflda: 2356
         ldstr: 3003
         ldtoken: 14
         type_from_handle: 546
         iid: 414
         adjusted_iid: 1831

By reducing the pieces that have to be patched to a small set of pages, the rest of the code can be shared across multiple Mono processes.

Now, with the same set of optimization flags, AOT code is slightly slower than JITed code because it has to be position independent and has to go through a few extra indirections that JIT code does not have to do (to maximize the sharing across applications).

The big news is that the new file format design has finally reached the point where using AOT code on day to day operations is faster than using JIT code. Building our core class libraries with our C# compiler with AOT code now takes less time than using the JIT-tuned version.

The mscorlib compilation consists of 262,261 lines of C# source code, the results are:

JIT time: 4.34 seconds

AOT time: 4.21 seconds

Today AOT is only available on the x86 and x86-64 ports of Mono, this seems to be good enough and where most of the desktop deployments will be.

Now, one common question we get is: if we already generate native code, how come you still need Mono to run your applications; or the variant of the question: can I produce statically generated executables that only contain native code?

It is currently not possible to generate merely a native code file because Mono still needs to extract the metadata from the original assembly file (the .dll or the .exe file), information that we do not encode in the AOT file format. In addition the generated image still requires the Mono runtime (for GC, Just-in-Time compilation services, reflection and a handful of extra features).

Mono does support a special mode that turns an assembly into a static binary, but it does not use native code, it still uses the JIT engine. This is done using the mkbundle command.

It is still possible to turn off the use of AOT files in a per-run basis, this can be done by passing the -O=-aot command line option to the runtime. In the upcoming version of Mono, all of our wrapper scripts will also support the MONO_OPTIONS variable to control this.

We are hoping to ship a script that will AOT all the libraries and executables that ship as part of Mono, or to disable all the AOT executables on demand in a future release of Mono.

Don asked me at the Lang.NET Symposium how we handled generics, and I have no idea.

Posted on 17 Aug 2006

Micro Glib Project Started

by Miguel de Icaza

I have started working on a micro version of glib that is suitable to be embedded with Mono and which is licensed under the MIT X11 terms. The code lives in mono/eglib in the Mono repository.

Posted on 16 Aug 2006

Open Sourcing of Avalon

by Miguel de Icaza

Jon Udell, following up to Joe Beda's follow up to the J2EE/Avalon post:

With 20/20 hindsight, Beda wishes things had been done differently: a smaller team, incremental releases. And he holds out some hope for the awkwardly named Windows Presentation Foundation/Everywhere (WPF/E), the lightweight, portable, .Net-based “Flash killer,” that I discussed in my interview with Bill Gates from the 2005 Professional Developers Conference.

The WPF/E runtime won’t implement all of XAML (XML Application Markup Language), a .Net language tuned for declarative application layout. But “the portion of XAML we’ve picked,” Gates told me, “will be everywhere, absolutely everywhere, and it has to be.”

“Everywhere” means the kind of ubiquity that the Flash player enjoys on Windows and Mac desktops, and to a lesser extent on Unix and handheld devices. And it sets up an arms race between Adobe and Microsoft, each giving away razors (that is, players) in order to sell blades (development tools).

Here’s a crazy idea: Open-source the WPF/E, endorse a Mono-based version, and make XAML an open standard. Why? Because an Adobe/Microsoft arms race ignores the real competition: Web 2.0, and the service infrastructure that supports it.

The HTML/JavaScript browser has been shown to be capable of tricks once thought impossible. Meanwhile, though, we’re moving inexorably toward so-called RIAs (rich Internet applications) that are defined, at least in part, by such declarative XML languages as Adobe’s MXML, Microsoft’s XAML, Mozilla’s XUL (XML User Interface Language), and a flock of other variations on the theme.

Imagine a world in which browsers are ubiquitous, yet balkanized by incompatible versions of HTML. That’s just where RIA players and their XML languages are taking us. Is there an alternative? Sure. Open XAML. There’s a stake in the ground that future historians could not forget.

Convenient use of HTML's <b> tag added.

Posted on 16 Aug 2006

Open Letter to the Heroes

by Miguel de Icaza

Are you adapting to win yet?

Posted on 16 Aug 2006

Liquids on a Plane.

by Miguel de Icaza

Last week, as the terror plot unfolded, Snapple and bottled water were banned from airplanes.

It is now the theme for Hollywood Movie

Posted on 15 Aug 2006

The Open Sourcing of Java

by Miguel de Icaza

Stephen Walli blogs about the open sourcing of Java. Stephen was at one of the meetings where Sun is discussing the open sourcing of Java.

About this move:

So Sun has a huge opportunity to “do it right” with Java. They began the release of Java EE 5 with the GlassFish project, and continue the work in the context of a culture shift that has delivered OpenSolaris. Now time will tell if they can harness all their collective experience in open source software, standards, and the JCP to bring about a complete open source Java world.

On Microsoft's positioning regarding Mono:

Microsoft continues to position mono as “an interesting science experiment” in its market commentary, despite its growing success, and to maintain an arm’s length ambiguity about the state and status of non-essential patents that may be infringed by mono.

Instead of encouraging multiple implementations of a standard they instigated, they discourage them. Instead of embracing open source collaborative development, innovation and contribution, they keep the community hobbled.

Posted on 15 Aug 2006

Mono User and Developers Conference

by Miguel de Icaza

We are having a user and developers conference for Mono users and developers on October 23 and 24th in Boston, MA.

The event is free, but we need to know how many people will be coming. Please register here.

Posted on 15 Aug 2006

George Galloway, take 2

by Miguel de Icaza

Duncan pointed me to a George Galloway interview on Sky News (the UK edition of Fox News).

The video is here.

Oh, and Chomsky has some good background as well. This bit is interesting:

Do you agree with the argument that Israel's military offensive in Lebanon is "legally and morally justified?"

Noam Chomsky: The invasion itself is a serious breach of international law, and major war crimes are being committed as it proceeds. There is no legal justification.

The "moral justification" is supposed to be that capturing soldiers in a cross-border raid, and killing others, is an outrageous crime. We know, for certain, that Israel, the United States and other Western governments, as well as the mainstream of articulate Western opinion, do not believe a word of that. Sufficient evidence is their tolerance for many years of US-backed Israeli crimes in Lebanon, including four invasions before this one, occupation in violation of Security Council orders for 22 years, and regular killings and abductions. To mention just one question that every journal should be answering: When did Nasrallah assume a leadership role? Answer: When the Rabin government escalated its crimes in Lebanon, murdering Sheikh Abbas Mussawi and his wife and child with missiles fired from a US helicopter. Nasrallah was chosen as his successor. Only one of innumerable cases. There is, after all, a good reason why last February, 70% of Lebanese called for the capture of Israeli soldiers for prisoner exchange.

Emphasis added.

Posted on 12 Aug 2006

Mexican Elections Fraud

by Miguel de Icaza

My father did his own study of the official results of the mexican election on July 2nd.

His first batch of results is here. The document is in Spanish and contains assorted awk and shell scripts to reproduce the studies in the comfort of your home.

His study of course, is much more rigorous and interesting than mine ;-)

Posted on 12 Aug 2006

John Gough on compiling Ruby to the CLI

by Miguel de Icaza

Sam Ramji, at Port25 interviews professor John Gough on his project to compile Ruby for .NET.

The interviews are here.

Posted on 09 Aug 2006

« Newer entries | Older entries »