# Monday, July 24, 2006

Almann Goo released version of JaCIL on Saturday. The goal of JaCIL is basically to be a reverse ikvmc, it converts .NET assemblies into Java jars.

The binary distribution includes a couple of demos. Naturally I had to try and run them on IKVM :-) I ran into two known IKVM bugs, the first being that JaCIL generates a class and prior to Java 1.5 this wasn't a valid class name, but since Java 1.5 the class name space has been significantly enlarged, almost all checks have been removed. The second bug was that Java classes with both a Finalize() and finalize() method would be compiled incorrectly (under the covers IKVM generates a Finalize() method that overrides System.Object::Finalize and calls java.lang.Object::finalize), I've added support for this by renaming the generated Finalize method when it is necessary.

JaCIL isn't yet at the point where it can compile the ikvmc generated assembly[*], but maybe we'll eventually be able to run Java on .NET on Java on .NET on Java on .NET on Java... ;-)

[*] If you try it, you'll likely to run into an IKVM limitation. JaCIL is a .NET application and uses an ikvmc compiled version of ObjectWeb ASM and currently, IKVM.Runtime.dll gets confused if multiple versions of IKVM.GNU.Classpath.dll are loaded in the AppDomain.

Monday, July 24, 2006 2:18:39 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, July 12, 2006
Eclipse 3.2 x64

The Eclipse 3.2 release also includes an "early access" version for Windows x64 (among other 64 bit platforms), so I decided to try to run this version on IKVM.

While trying this I discovered a bug in the 64 bit version of the CLR. It doesn't respect MethodImpl(MethodImplOptions.NoInlining) and this means that Eclipse fails to start up, because it still does that weird stack walking to make sure that a particular method is called by the expected caller. BTW, instead of using the stack trace from an exception, they now use a subclass of SecurityManager and call getClassContext on that. That mechanism is a little better, but it is still incredibly lame.

The good news is that after adding a hack to IKVM to insert some extra junk in that particular method that prevents it from being inlined, Eclipse 3.2 x64 seems to run fine on IKVM.

Coincidentally, Eclipse 3.2 doesn't work on IKVM, because my implementation of getClassContext returned one stack frame too few (the GNU Classpath VMStackWalker interface is somewhat inconsistent, the other two methods in it both skip two frames, but getClassContext is apparantly only supposed to skip one frame).

Update: I got an e-mail from someone on the CLR team and he explained that the observed behaviour is by design. The method is not inlined, but the JIT optimizes the call into a tail call, thereby removing the stack frame from the call stack. Strictly speaking this is indeed a legal optimization, but I have to say I don't really see the point, if I wanted a tail call I would have used the tail call instruction.

Wednesday, July 12, 2006 4:59:45 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Wednesday, July 5, 2006
Eclipse Java Compiler

The recent Eclipse 3.2 release includes a release of the stand alone Eclipse Java Compiler (they call it the JDT Core Batch Compiler). It is available as ecj.jar.

I switched to using this version for building GNU Classpath. If you want to use the same version, simply download ecj.jar and run it through ikvmc.

Wednesday, July 5, 2006 5:23:41 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]