# Friday, 25 February 2011
CLR Type Names

Type names look like a simple concept. Every type has a unique name within the assembly that defines it.

It turns out that there is a slight complication. Even though the CLI specification and the reflection API suggest that a type name is simply a string, in reality it is a pair of strings: { namespace, name }

Here's some code that uses IKVM.Reflection to generate an interesting assembly:

using IKVM.Reflection;
using IKVM.Reflection.Emit;

class Program {
  static void Main() {
    var universe = new Universe();
    var ab = universe.DefineDynamicAssembly(new AssemblyName("Test"), AssemblyBuilderAccess.Save);
    var modb = ab.DefineDynamicModule("Test", "Test.dll");
    modb.__DefineType("A.B", "C").CreateType();
    modb.__DefineType("A", "B.C").CreateType();
    ab.Save("Test.dll");
  }
}

This creates a valid (and verifiable) assembly containing two different types, both named A.B.C.

If you disassemble this assembly with ildasm and the resulting IL is reassembled with ilasm you won't end up with the same assembly. I don't know if there are any obfuscators that use this trick, but maybe they should.

Reflection APIs assume that the last dot in the type name separates the namespace from the name, so doing Type.GetType("A.B.C") will return the first type {"A.B", "C"}. You can get the second type by enumerating all types in the assembly.

Note that static binding just works, because in that case the {namespace, name} pair is specified explicitly.

Friday, 25 February 2011 09:09:01 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Monday, 21 February 2011
Exception Performance Part 3

This is the final part of three part series on exception performance that started in 2008. Previous parts are:
Exception Performance Part 1
Exception Performance Part 2

Let's introduce a slight variation of ExceptionPerf1 where we throw 10000 exceptions instead of 100000 and throw the exception from a method, instead of directly in the loop.

using System;
using System.Diagnostics;

class ExceptionPerf5 {
  static void Main() {
    var sw = Stopwatch.StartNew();
    for (int i = 0; i < 10000; i++) {
      try {
        Foo();
      } catch { }
    }
    sw.Stop();
    Console.WriteLine(sw.ElapsedMilliseconds);
    Console.ReadLine();
  }

  private static void Foo() {
    throw new Exception();
  }
}

When this is compiled with the standard Debug configuration in Visual Studio 2010 it yields the following performance numbers (times in milliseconds) when run either with Ctrl-F5 (i.e. no debugger attached) or F5 (debugger attached):

  HotSpot 1.6 .NET 2.0 .NET 4.0
  x86 x86 x64 x86 x64
Ctrl-F5 25 286 413 292 305
F5   16950 16134 45223 114790

For comparison, the table also includes the time it takes to run the equivalent code in HotSpot 1.6 Client VM on x86.

As we saw in the previous two articles on exception performance, .NET is significantly slower in handling exceptions, so that is not surprising. However, what is surprising is how much the overhead is of simply having the debugger attached.

Another depressing thing to note is that things have gotten much worse with .NET 4.0.

Unfortunately, many developers have the habit of always running their code in the debugger, so when they first try code IKVM.NET compiled code from within Visual Studio they often get a very bad impression of the performance, simply because the debugger sucks.

I considered filing a connect bug for this, but you know they'll just close it as By Design. I guess the CLR is only a Common Language Runtime, if you language doesn't use exceptions for control flow.

Monday, 21 February 2011 09:46:12 (W. Europe Standard Time, UTC+01:00)  #    Comments [5]
# Thursday, 17 February 2011
Mono 2.10 Released

Mono 2.10 was released this week. It includes a version of the Mono C# compiler that uses IKVM.Reflection as its back end.

Last year in the two days before FOSDEM I hacked mcs to use IKVM.Reflection and while at FOSDEM I showed this hack to Miguel and was met with his usual enthusiasm and he told me that he was already planning on talking to me about using IKVM.Reflection for mcs.

In May, Kornél Pál did a, much more complete than my hack, prototype port of mcs to IKVM.Reflection and that resulted in a number of IKVM.Reflection bug fixes and enhancements.

Last November, Marek Safar starting work on integrating IKVM.Reflection support for real and made sure that everything was production ready. This resulted in some mcs restructuring and yet more IKVM.Reflection fixes, features and also performance improvements.

The result of all this is that now IKVM.Reflection is a great library to use if you have a codebase that has both a dynamic and a static compilation mode (as both IKVM.NET and mcs have), because you can easily share the bulk of your code between System.Reflection and IKVM.Reflection without having to suffer from the (significant) limitations of System.Reflection for the static scenario.

Thursday, 17 February 2011 06:59:38 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Tuesday, 15 February 2011
New Development Snapshot

I decided to delay the 0.46 release to wait for OpenJDK 6 build 22, which will be a security update and should be available soon. In the mean time, here is a new development snapshot.

Changes:

  • Fixed some compilation warnings.
  • Fix for the timezone used to convert .NET DateTime to Java timezone in the JDBC-ODBC bridge.
  • Fix for bug # 3129981.
  • Fixed .NET 4.0 build verification issue.
  • IKVM.Reflection: Enabled framework unification support.
  • IKVM.Reflection: Avoid re-firing the assembly resolve event for missing assemblies.
  • IKVM.Reflection: Several performance tweaks by Marek Safar.
  • IKVM.Reflection: Added feature to (optionally) allow resolving of missing methods.
  • IKVM.Reflection: Added [Constructor|Method]Builder.__ReleaseILGenerator() API to eagerly bake the method body and release the ILGenerator.

Binaries available here: ikvmbin-0.45.4062.zip

Tuesday, 15 February 2011 07:54:58 (W. Europe Standard Time, UTC+01:00)  #    Comments [1]