# Wednesday, 03 March 2004
Object Model Mapping Part 3

A brief update on the progress and some random thoughts on remapping. Today I got classpath.dll to build (and verify) for the first time using the new remapping infrastructure. Finally some progress. However, there is still some more work to do before it runs again.

Part of the new model is that there are now two different type wrappers (the internal class that contains the meta data of an IKVM type) for the remapped types. There is one type wrapper that is used during static compilation (RemapperTypeWrapper) and another one that is used during at runtime (CompiledTypeWrapper, also used for normal (i.e. non-remapped) statically compiled classes). The advantage of this is that there is less overhead at runtime and the code is also a bit less complex. This is also the final step in an invisible process that has been going on for a long time. It is now no longer possible to run IKVM without a statically compiled classpath.dll (it hasn't been possible for a while, but theoretically it could have been made to work). When I just got started, there was no static compiler yet and the only way for it to work was to load all classes dynamically, after the static compiler started to work, support for dynamically loading the core classes began to degenerate. That degeneration is now final and there is no way back ;-)

What's next?

More metadata needs to be emitted on the remapped types and CompiledTypeWrapper needs to be changed to understand it. The code needs to be cleaned up. I'm not sure yet, but I think a lot of complexity can be removed now. Virtual method invocation needs to be optimized. At the moment all virtual method call to remapped types go through the helper methods, but this is only needed is the reference type is not know to be a Java subclass. For example, calling java.lang.Object.toString() on a java.lang.Object reference requires the call to go through the helper method, but calling java.lang.Object.toString() on java.lang.Math (this is just a random example) doesn't need to go through the helper method.

Of course, there are also various loose ends that need to be tied up, but I think I'm on track to have a working version sometime next week.

More FOSDEM

Patrik posted an overview of the FOSDEM Java talks. It also includes links to the slides for some of the talks.

Wednesday, 03 March 2004 20:59:25 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Monday, 01 March 2004
Object Model Mapping Part 2

In yesterday's entry I didn't get to the stuff that kept me going in circles last week. I had decided on the mixed model a few months ago, but as usual the devil is in the details.

Initially I wanted to keep the map.xml format more or less the same and I think that put me on the wrong track. Let's start by taking a look at some of the current map.xml features. Within the <class> tag there are <constructor> and <method> tags. These can contain several different child tags:

  • Empty (i.e. no child tags)
    The method is identical to the corresponding method in the underlying type. Example: The constructor of java.lang.Object is identical to the constructor of System.Object, so the tag looks like this:
    <constructor sig="()V" modifiers="public" />
  • <redirect>
    The method is redirected to another method. This can be a static method in a helper class or a static or instance method in the underlying type. Example: java.lang.Object.notifyAll() is redirected to System.Threading.Monitor.PulseAll():
    <method name="notifyAll" sig="()V" modifiers="public final">
        <redirect class="System.Threading.Monitor, mscorlib" name="PulseAll" sig="(Ljava.lang.Object;)V" type="static" />
    </method>
  • <invokespecial>
    If the method is invoked using the invokespecial bytecode, this CIL sequence is emitted. Example: java.lang.Object.wait() is implemented by calling System.Threading.Monitor.Wait(), but Monitor.Wait returns a boolean that has to be discarded:
    <method name="wait" sig="()V" modifiers="public final">
        <invokespecial>
            <call type="System.Threading.Monitor, mscorlib" name="Wait" sig="(Ljava.lang.Object;)Z" />
            <pop />
        </invokespecial>
    </method>
  • <invokevirtual>
    Similar to <invokespecial>, but this defines the CIL that is emitted when the invokevirtual bytecode is used to call the method.
  • <override>
    Specifies that this method conceptually overrides the method named in the <override> tag. I say "conceptually" because in the equivalence model there is no real class. However, if a real subclass would override this method, it would actually be overriding the method named in the override tag. Example: java.lang.Object.hashCode() overrides System.Object.GetHashCode:
    <method name="hashCode" sig="()I" modifiers="public">
        <override name="GetHashCode" />
        <invokevirtual>
            <dup />
            <isinst type="System.String, mscorlib" />
            <brfalse name="skip" />
            <castclass type="System.String, mscorlib" />
            <call class="java.lang.StringHelper" name="hashCode" sig="(Ljava.lang.String;)I" />
            <br name="end" />
            <label name="skip" />
            <callvirt type="System.Object, mscorlib" name="GetHashCode" />
            <label name="end" />
        </invokevirtual>
    </method>
  • <newobj>
    Used in constructors to define the CIL that is emitted when a new instance is created. Example: java.lang.String has a default constructor, but System.String doesn't:
    <constructor sig="()V" modifiers="public">
        <newobj>
            <ldstr value="" />
            <call type="System.String, mscorlib" name="Copy" />
        </newobj>
    </constructor>

The thing to note is that some of the remapping implications are still handled manually in this scheme. For example, the <invokevirtual> of Object.hashCode has to check for string instances. This information can be derived from the remapping file and it shouldn't be necessary to do this explicitly.

I didn't really like the <invokespecial> and <invokevirtual> constructs and I explored the idea of only having a <body> tag that contains the method body. However, it soon became clear that that wouldn't be enough. For example, the implementation of java.lang.Object.clone needs to call the protected method System.Object.MemberwiseClone and this is only allowed in subclasses. So it wouldn't be possible to generate a verifiable helper method for that.

The obvious solution (in hindsight) came to me when I realised that there are actually two types of "subclasses" of java.lang.Object, the ones that really extend java.lang.Object (our generated .NET type) and the ones that don't (e.g. arrays, System.String and all other .NET types). I knew this before, of course, but I was trying to make the model too general. After this realisation, it became obvious that every method should have a <body> and an <alternateBody> (tentative names).

After I've modified the remapping engine to automatically handle all the overridden method implications, the <alternateBody> construct will not be needed for many methods. I think only for Object.clone and Object.finalize and both will be trivial. The <alternateBody> for clone will throw a CloneNotSupportedException (it could also check if the object implements ICloneable and if so, invoke that Clone method, but does this really help?) and the <alternateBody> for finalize will simply be empty, since there is no good reason to ever explicitly invoke the Finalize method of a .NET type.

As an aside, I'm also going to remove the <redirect> construct, because it doens't really add any value. It's just as easy to have a <body> with a <call>.

I'm not clear on the performance implications of these changes. In the existing model, many of the remapping constructs are inlined, but in the new model they won't be, invokespecial will end up calling the real method in the new classes and invokevirtual will call the static helper method. This will probably be slightly slower, but I think the other advantages easily outweigh this.

Another advantage of this scheme that I didn't yet mention is that reflection on remapped methods is now trivial. Currently, the following program doesn't work on IKVM, in the new model the call would simply end up at the static helper method for clone:

class ReflectClone
{
  public static void main(String[] args) throws Exception
  {
    java.lang.reflect.Method m;
    m = Object.class.getDeclaredMethod("clone", new Class[0]);
    m.setAccessible(true);
    System.out.println(m.invoke(args, new Object[0]));
  }
}

BTW, I originally tried this by getting the public clone method on the array class, but oddly enough on the Sun JVM array types don't appear to have a public clone method (even though you can call it just fine!).

Monday, 01 March 2004 10:59:33 (W. Europe Standard Time, UTC+01:00)  #    Comments [4]
# Sunday, 29 February 2004
Object Model Mapping

After suffering from coder's block (if that's the programmer's equivalent of writer's block) for weeks, I finally got started the past week on the new object model remapping infrastructure. I spent most of the week going in circles. Writing code, deleting it, writing more code, deleting it again. However, I think I figured it out now. To test that theory I decided to write a blog entry about it. Explaining something is usually a good way to find holes in your own understanding.

I'm going to start out by describing the problem. Then I'll look at the existing solution and it's limitations. Finally I'll explain the new approach I came up with. If everything goes well, by end the of the entry you'll be wondering "why did it take him so long to come up with this, it's obvious!". That means I came up with the right solution and I explained it well.

Note that I'm ignoring ghost interfaces in this entry. The current model will stay the same. For details, see the previous entries on ghost interfaces.

What are the goals?

  • We need a way to have the Java object model fit into the .NET model
  • We would like to enable full interoperability between the two models
  • Performance should be acceptable
  • Implementation shouldn't be overly complex

The .NET model (relevant types only):

For comparison, here is the Java model that we want to map to the .NET model:

There are several possible ways to go (I made up some random names):

  • Equivalence
    This is the current model. The Java classes are mapped to the equivalent .NET types. This works because System.Object has mostly the same virtual methods as java.lang.Object. For the java.lang.Throwable to System.Exception, a little more work is needed and that is where the java.lang.Throwable$VirtualMethods interface comes in. When a virtual method on Throwable is called through a System.Exception reference, the compiler calls a static helper method in Throwable$VirtualMethodsHelper that checks if the passed object implements the Throwable$VirtualMethods interface and if so, it calls the interface method, if not, it calls the Throwable implementation of the method (i.e. it considers the method not overridden by a subclass). A downside of using an interface for this is that all interface methods must be public, at the moment this isn't a problem because all virtual methods (except for clone and finalize derived from Object) in Throwable are public, but it could become a problem later on.
  • Extension
    This is a fairly straightforward approach where java.lang.Object extends System.Object and the Java array, String and Throwable classes are simply subclasses of java.lang.Object. It is easy to implement. The obvious downsides are that arrays will be slow (extra indirection), Strings need to be wrapped/unwrapped when doing interop with .NET code and Throwable is not a subclass of System.Exception (the CLI supports this, but once again not a good idea for interop).
  • Wrapping
    I apologise in advance, because I probably can't explain this one very well (because it doesn't make any sense to me). Many people have actually suggested this model. In the model java.lang.Object extends System.Object, but arrays, String and Throwable do not extend java.lang.Object, instead whenever an instance of those types is assigned to a java.lang.Object reference, it is wrapped in an instance of a special java.lang.Object wrapper class. The downside of this model is that wrapping and unwrapping is expensive and (and this is why I don't like this approach at all) that the expense is paid in ways that are very unexpected to the Java programmer (who expects simple assignment to be expensive?).
  • Mixed
    This is the new model. Explanation follows below.

What's wrong with equivalance?

Both J# and the current version of IKVM use equivalence (although many of the details differ and J# doesn't consider Throwable and System.Exception to be equivalent) and it works well. So why change it? There are four advantages to the mixed model:

  • Interop works better
    In the current model, if you subclass a Java class from C# and you want to override Object.equals, depending on whether any of the base classes overrides Object.equals you need tot override either Equals or equals. If you want to call Throwable.getStackTrace() from C# on a reference of type System.Exception there is no obvious way to do that.
  • More efficient representation of remapping model
    Currently every subclass of java.lang.Object overrides toString() to call ObjectHelper.toStringSpecial, this is needless code bloat. More importantly, before any classes can be resolved the map.xml remapping information needs to be parsed and interpreted (to know about java.lang.Object, java.lang.String and java.lang.Throwable). In the new model, java.lang.Object, java.lang.String and java.lang.Throwable will be in the classpath.dll, so they can be resolved on demand. The classes will be decorated with custom attributes to explain to the runtime that they are special, but no other metadata will need to be parsed or interpreted.
  • Cleaner model
    java.lang.ObjectHelper and java.lang.StringHelper no longer need to be public and the various $VirtualMethod helper types aren't needed anymore.
  • Easier to get right
    There are a few subtle bugs in the current implementation. Try the following for example:
    class ThrowableToString
    {
      public static void main(String[] args) throws Exception
      {
        String s = "cli.System.NotImplementedException";
        Object o = Class.forName(s).newInstance();
        Throwable t = (Throwable)o;
        System.out.println(o.toString());
        System.out.println(t.toString());
      }
    }
    
    It prints out:
    System.NotImplementedException: The method or operation is not implemented.
    cli.System.NotImplementedException: The method or operation is not implemented.
     

    Obvously, both lines should be the same. Another (at the moment theoretical) problem is that it is legal for code in the java.lang package to call Object.clone or Object.finalize (both methods are protected, but in Java, protected also implies package access), currently that wouldn't work.

Here is the mixed model I ended up with:

I called it mixed because it combines some features of equivalence and extension. For example, references of type java.lang.Object are still compiled as System.Object (like in the equivalence model), but the non-remapped Java classes extend java.lang.Object (like in the extension model).

java.lang.Object will contain all methods of the real java.lang.Object and in addition to those also a bunch of static helper methods that allow you to call java.lang.Object instance methods on System.Object references. The helper methods will test if the passed object is either a java.lang.Object or a java.lang.Throwable (for virtual methods) and if so, it will downcast and call the appropriate method on those classes, if not, it will perform an alternative action (that was specified in map.xml when this classpath.dll was compiled).

Object.finalize requires some special treatment since we don't want java.lang.Object.finalize to override System.Object.Finalize because that would cause all Java objects to end up on the finalizer queue and that's very inefficient. So the compiler will contain a rule to override System.Object.Finalize when a Java class overrides java.lang.Object.finalize.

I glossed over a lot of details, but those will have to wait for next time.

FOSDEM 2004

Finally a short note on FOSDEM (Free and Open Source Software Developer's Meeting). Last weekend I visisted FOSDEM in Brussels. I enjoyed seeing Dalibor, Chris, Mark, Sascha and Patrik again and I also enjoyed meeting gjc hackers Tom Tromey and Andrew Haley for the first time. Mark wrote up a nice report about it. If you haven't read it yet, go read it now. All in all a very good and productive get-together.

Sunday, 29 February 2004 15:43:01 (W. Europe Standard Time, UTC+01:00)  #    Comments [1]
# Wednesday, 18 February 2004
F.A.Q.

Stuart pointed out the F.A.Q. was out of date, so I updated it a little bit. He also asked:

Speaking of which, I noticed while perusing the FAQ that the JIT compiler is included in IK.VM.NET.dll which means it's required for running even statically-compiled code. For apps that don't use clever classloading tricks, the JIT isn't needed at all when everything's been statically compiled. Would it be possible to separate the JIT out into a different DLL to reduce the necessary dependencies for a statically-compiled Java app?

Sure, the 275K of IK.VM.NET.dll is miniscule compared to the 3Mb of classpath.dll, but it's the principle of the thing ;)

This is definitely something I want to do. In fact, I would also like to have the option to only include parts of the Classpath code when statically compiling a library. So instead of having a dependency on classpath.dll, you'd suck in only the required classes.

Wednesday, 18 February 2004 09:36:11 (W. Europe Standard Time, UTC+01:00)  #    Comments [4]
# Monday, 16 February 2004
Jikes 1.19, Bytecode Bug, Serialization and a New Snapshot
 

Jikes

I upgraded to Jikes 1.19 that was released recently. It didn't like the netexp generated stub jars (which is good, because it turns out they were invalid), so I fixed netexp to be better behaved in what it emits. Jikes didn't like the fact that the inner interfaces that I created had the ACC_STATIC modifier set at the class level, rightly so, but the error message it came up with was very confusing. Along the way I also discovered that it is illegal for constructors to be marked native (kind of odd, I don't really see why you couldn't have a native constructor). So I made them non-native and have a simple method body that only contains a return. That isn't correct either (from the verifier's point of view) and I guess I should change it to throw an UnsatifiedLinkError. That would also be more clear in case anyone tries to run the stubs on a real JVM.

Jikes 1.19 has a bunch of new pedantic warnings (some enabled by default). I don't think this is a helpful feature at  the moment. Warnings are only useful if you can make sure you don't get any (by keeping your code clean), but when you already have an existing codebase, this is very hard and in the case of Classpath, where you have to implement a spec, you often don't have the option to do the right thing. So I would like to have to option to have lint like comment switches to disable specific warnings in a specific part of the code.

Bytecode Bug

I also did some work to reduce the number of failing Mauve testcases on IKVM and that caused me to discover that the bit shifting instructions were broken (oops!). On the JVM the shift count is always masked by the number of bits (-1) in the integral type you're shifting. So for example:

int i = 3;
System.out.println(i << 33);

This prints out 6 ( 3 << (33 & 31)). On the CLI, if the shift count is greater than the number of bits in the integral type, the result is undefined. I had to fix the bytecode compiler to explicitly do the mask operation.

Serialization

Brian J. Sletten reported on the mailing list that deserialization was extremely slow. That was caused by the fact that reflection didn't cache the member information for statically compiled Java classes or .NET types. I fixed that and after that I also made some improvements to GNU Classpath's ObjectInputStream to speed it up even more. It's still marginally slower than the Sun JRE, but the difference shouldn't cause any problems.

Snapshot

I made a new snapshot. Here's what's new:

  • Changed classpath.build to disable jikes warnings (I know it's lame, but I grew tired of the useless warnings). I also added the -noTypeInitWarning option to ikvmc, to get rid of all the warning about running type initializers.
  • Implemented accessibility checks for Java reflection.
  • Cleaned up socket code and implemented all of the socket options (well, except for IP_MULTICAST_IF2).
  • Implemented Get###ArrayRegion/Set###ArrayRegion and GetPrimitiveArrayCritical/SetPrimitiveArray JNI functions.
  • Added all the 1.4 functions to the JNIEnv vtable.
  • Implemented support for field name overloading (a single class can have several different fields with the same name, if the types are different).
  • Changed the class format errors thrown by ClassFile.cs to .NET exception, instead of Java exception, to have better error handling in ikvmc.
  • Changed VMClass.getWrapperFromClass to use a delegate instead of reflection, to speed up reflection.
  • Fixed the compiler to mask shift counts for ishl, lshl, iushr, lushr, ishr, lshr bytecodes.
  • Fixed a bug in ghost handling (the bug could cause a "System.NotSupportedException: The invoked member is not supported in a dynamic module." exception).
  • Added EmitCheckcast and EmitInstanceOf virtual functions to TypeWrapper.
  • Added a LazyTypeWrapper base class for DotNetTypeWrapper and CompiledTypeWrapper, to cache the member information to speed up reflection.
  • Improved error handling in ikvmc.
  • Fixed netexp to generate valid (or less invalid) classes.
  • Regenerated (and checked in) mscorlib.jar, System.jar and System.Xml.jar with the new (fixed) version of netexp.

I didn't get around yet to removing the "virtual helpers" and introducing base classes for non-final remapped types (java.lang.Object and java.lang.Throwable).

New snapshots: just the binaries and source plus binaries.

Monday, 16 February 2004 16:33:14 (W. Europe Standard Time, UTC+01:00)  #    Comments [1]
# Sunday, 11 January 2004
New Snapshot
I made a new snapshot. Here's what's new:
  • Renamed Type property of TypeWrapper to TypeAsTBD. This is to make clear that eventually all references to TypeAsTBD should be removed (a more specific TypeAsXXX should be used).
  • Changed several InvalidOperationException tests to assertions.
  • Changed JavaAssemblyAttribute to JavaModuleAttribute. In the future this attribute will go away and be replaced by an attribute that is attached to each type. This is to support linking Java and non-Java types into the same (single file) assembly with the Whidbey linker.
  • Removed getTypeFromWrapper, getWrapperFromType, getType and getName from VMClass and added getWrapperFromClass.
  • Added TypeWrapper.RunClassInit.
  • Fixed serialization and reflection to be able to call constructor on already allocated objects.
  • Added class accessibility checks in various places.
  • Added EmitCheckCast and EmitInstanceOf to TypeWrapper.
  • Changed all .NET type names in map.xml to partially qualified names.
  • Added -target:module support to ikvmc.
  • Added assembly signing support to ikvmc.
  • Added option to set assembly version to ikvmc.
  • Fixed bug in ikvmc that caused crash if jar contained a manifest.
  • Inner class support for native methods that are mapped to NativeCode.* classes.
  • Miscellaneous clean up and restructuring.

Most of this is clean up and restructuring to facilitate the next major change, removing the "virtual helpers" and introducing base classes for non-final remapped types (java.lang.Object and java.lang.Throwable).

New snapshots: just the binaries and source plus binaries.

Sunday, 11 January 2004 14:23:27 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Saturday, 27 December 2003
dasBlog

I switched from blogX to dasBlog. Mainly because Chris is no longer maintaining blogX, but also because I wanted some new functionality.

Hopefully the transition will be smooth, but if something is not working please let me know.

Saturday, 27 December 2003 19:24:44 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
C# Shortcoming?
Tomas Restrepo posted some weird C# code on his weblog. It inspired me to test a few more corner cases:

namespace System {
   class Object { }
class ValueType { }


struct Int32 { }
class String { }
class A : string { public static void Main() { string s = new A(); } } }

If you compile this and then run peverify on the resulting executable, it will complain about every single type. Here is what's going on:

  • Object doesn't have a base class
  • ValueType extends our Object not the one in mscorlib
  • Int32 extends our ValueType
  • String extends our Object
  • A extends our String, but the local variable s is of type [mscorlib]System.String, so the assignment is not legal.

An obvious explanation for this (broken) behavior of the C# compiler is that Microsoft use the C# compiler to build mscorlib.dll. When compiling mscorlib.dll, the above behavior makes perfect sense. Of course, when you're not compiling mscorlib.dll, it doesn't make much sense and, in fact, it violates the language specification. For example, section 4.2.3 says:

       The keyword string is simply an alias for the predefined class System.String.

"predefined" being the important word here.

I guess it would be relatively easy to fix the compiler, but I think that there is actually an underlying problem: The C# language doesn't have support for assembly identities. Besides the above corner cases, this also causes problems in more real world situations.

Saturday, 27 December 2003 13:06:10 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Wednesday, 24 December 2003
Oops!

Last week's snapshot had a nasty bug. The code to copy the stack contents out of an exception block reversed the stack order. Not a good thing. A pretty stupid bug, but in my defense, this problem didn't show up with my Mauve tests compiled with Jikes. It only showed up on Eclipse (which I didn't have installed at the time). Thanks to Zoltan Varga for bringing this bug to my attention.

I've updated the snapshots. I also made some additional changes:

  • ikvmc now sniffs the name of the main class from the Jar manifest, if it exists.
  • Made loading of core Java classes used by the runtime more consistent. Introduced a new method ClassLoaderWrapper.LoadClassCritical and removed ClassLoaderWrapper.GetType (which had a similar but less well defined role).
  • Fixed some bugs related to -Xsave.
  • Introduced TypeWrapper.MakeArrayType to construct array types.
  • Added CodeEmitter.InternalError for emitters that should never be called (it throws an InvalidOperationException when its Emit method is called).
  • Cleaned up the warning message that shows up in netexp (and now also in ikvmc) that tells you that type initializers are being run when they shouldn't (due to a .NET runtime bug). The warning now only shows up if your .NET runtime has the bug.
  • Removed ThrowHack and changed the compiler to now always emit verifiably code when injecting exception throwing code (e.g. for illegal access errors).
  • Cleaned up JavaException.cs.
  • Changed MethodWrapper.GetExceptions to return string array and resolve these to classes on the Java side.
  • Fixed various bugs related to unloadable classes. The code generated to start up Eclipse is now totally verifiable (except for the JNI calls, of course).
  • Fixed reflection code to report assembly scoped methods and fields to be private when reporting on .NET assembly that was not generated by IKVM.NET.
  • Fixed TypeWrapper.IsInSamePackage to handle array types correctly.
  • Added a JVM.CriticalFailure method that is called when something is really wrong in the runtime (e.g. LoadClassCritical failed or an unexpected exception occurred in the bytecode compiler).
  • Added a JniProxyBuilder (for development and testing only) that splits out the JNI methods into a separate module, so that the peverify errors that are produced can be easily filtered out.
  • Reimplemented class accessibility checks in bytecode compiler (they've been broken for a long time, since I started adding support for unloadable classes).

New snapshots: just the binaries, source plus binaries and GNU Classpath.

Wednesday, 24 December 2003 12:53:05 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Friday, 19 December 2003
Building IKVM.NET on Mono/Linux

I installed Debian 3.0r1 in VMware to work on getting IKVM.NET to build on Mono.

I put together a new snapshot, this time including a GNU Classpath snapshot, because of the compromise of the FSF CVS server my Classpath sources differ from what's available in CVS.

Here are the steps required to build IKVM.NET on Mono on Debian:

  • Download and extract Mono 0.29 runtime and C# compiler
  • Comment out the line
    [assembly: AssemblyKeyFile("..\\..\\bytefx.snk")]
    in mcs-0.29/class/ByteFX.Data/AssemblyInfo.cs.
  • Make the HasShutdownStarted property in mcs-0.29/class/corlib/System/Environment.cs static and change it to return false instead of throw a NotImplementedException.
  • cd mono-0.29
  • ./configure && make && make install
  • cd ../mcs-0.29
  • make && make install
  • Download and extract Jikes 1.18
  • cd jikes-1.18
  • ./configure && make && make install
  • Download NAnt 0.84-rc1
  • mkdir nant-0.84
  • cd nant-0.84
  • unzip ../nant-0.84.zip
  • Comment out the class constructor (static CompilerBase() { ... }) in src/NAnt.DotNet/Tasks/CompilerBase.cs.
  • make clean && make
  • Create a nant shell script in /usr/local/bin that contains:
    #!/bin/sh
    /usr/local/bin/mono /usr/local/src/nant-0.84/bin/NAnt.exe "$@"
  • Create a dummy peverify shell script, that contains:
    #!/bin/sh
  • Download and unzip classpath.zip (don't run any of the scripts)
  • Download and unzip ikvm.zip
  • cd ikvm
  • nant clean
  • nant

Note: I have not yet integrated Zoltan Varga's JNI provider for Mono and the (broken) Windows Forms based AWT is not built on Mono.

Here is what's new since the last snapshot:

  • Changed build process to work on Mono/Linux.
  • Added flag to bytecode metadata table to see if an instruction can throw an exception. The compiler can use this optimize away useless exception blocks.
  • Changed constant pool constant handling to stop boxing the values and use type based accessors instead.
  • Fixed handling of ConstantValue attribute (now works for static fields regardless of whether they are final are not).
  • Exception remapping is now defined in map.xml. This allows more efficient exception handlers, because the compiler now understand the exception hierarchy (including the constraints imposed by the remapping).
  • Changed handling of netexp exported classes to be more robust in the face of errors (on Mono some of the mscorlib.jar classes are not (yet) present in mscorlib.dll).
  • Fixed emitting of DebuggableAttribute (the attribute was attached to the module, but it should be attached to the assembly).
  • Moved most of ExceptionHelper.cs to ExceptionHelper.java and changed the runtime to generate the exception mapping method from map.xml.
  • Fixed some ghost related bugs.
  • Added a test to supress the type initializer bug warning (during netexp) on runtimes that are not broken.
  • Moved common conversion emit operations to TypeWrapper (EmitConvStackToParameterType & EmitConvParameterToStackType).
  • Added test in JavaTypeImpl.Finish to make sure that we are not in "phase 1" of static compilation. During phase 1, classes are being loaded and no compilation should occur, if it does get triggered it is because of a bug in the compiler or a compilation error during compilation of the bootstrap classes.
  • Changed loading of java.lang.Throwable$VirtualMethods so that the ClassNotFound warning doesn't occur any more.
  • Added (partial) support for private interface method implementations to reflection. This fixes a bug in netexp, that caused classes that use private interface implementation to be unusable from Java (because they appear abstract, because of the missing method).
  • Removed WeakHashtable.cs. Exception mapping code is now written in Java and uses java.util.WeakHashMap.
  • Removed StackTraceElement class from classpath.cs. Exception mapping code is now written in Java and uses the GNU Classpath StackTraceElement.java.
  • Moved java.lang.Runtime native methods to Java (except for getVersion and nativeLoad). This is based on a new split of java.lang.Runtime and java.lang.VMRuntime that hasn't been checked into Classpath yet.
  • Many changes to the bytecode compiler to emit more efficient (actually less inefficient) code for exception handlers.
  • Added workaround to bytecode compiler to Improve debugging line number information.
  • Various bug fixes and some clean up of bytecode compiler.
  • Made ikvmc more user-friendly. It now guesses all options based on the input. You can now do "ikvmc HelloWorld.class" and it will generate HelloWorld.exe (if HelloWorld.class has a main method, if not it will generate HelloWorld.dll).
  • Fixed DotNetProcess (that implement Runtime.exec) to handle environment variable duplicates properly.
  • Removed support for throwing arbitrary exceptions using Thread.stop(Throwable). You can now only throw arbitrary exceptions on the current thread or ThreadDeath exceptions on other threads.
  • Implemented shutdown hooks.
  • Changed ikvm.exe to use a more compatible way of finding the main method and to always run the static initializer of the main class (even if the main method is missing).
  • The ikvm -Xsave option is now implemented using a shutdown hook. This allows it to work even if the application terminates with System.exit().

New snapshots: just the binaries, source plus binaries and GNU Classpath.

Friday, 19 December 2003 14:56:15 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]