[Mono-devel-list] .NET Blog on performance.

Ben Maurer bmaurer at ximian.com
Sat Oct 23 16:24:43 EDT 2004

On Sat, 2004-10-23 at 13:53 -0400, Miguel de Icaza wrote:
> The other issue is that AOT code makes code slower, because the code
> basically is "shared" so loads to static variables or static method
> invocations have to be dereferenced and this might impact performance.

This is not correct.

What happens when you AOT code and it is used in multiple app domains

- The code is compiled as it normally is for the jit. If you need to
(say) load a static field, we emit code like this:

0x10:   mov eax, 0x00000000 
0x15:   mov eax, [eax]

In the static data, we have information that looks basically like:

Offset   Patch type                    Patch data
0x15     PATCH_TYPE_STATIC_FIELD       0xdeadbeef

When the runtime needs to jit the method, it will see that we already
have the jitted data in the aot. The runtime will then look at the patch
table. It will see that the method has a patch at offset 0x10. When the
code is copied into memory, it will be copied as

0x10:   mov eax, 0xcafebabe
0x15:   mov eax, [eax]

So, the story for loading a static field (or calling a static method,
etc) is about the same as it was for the JIT story. The only difference
was the extra mov that we emitted. Today, this is one of the
disadvantages of aot -- we are not able to patch some patterns, say

mov eax, [0xcafebabe]

So, we resort to longer patterns mov eax, blah, mov eax, [eax]. It is
slightly sub-optimal, but not horrific.

In order to handle multiple appdomains, we make copy and patch the code
for each appdomain, just as code is jitted for each appdomain.

You can use mono -v -v -v --aot ... to see the code that is being
generated by aot.

(you can run mono -O=shared --aot to get the shared code. Of course this
will run sower, however it will not need to be loaded per-ad)

Ben Maurer <bmaurer at ximian.com>

More information about the Mono-devel-list mailing list