# Tuesday, 22 February 2005
Stack Traces

Corey comments on the previous entry:

While I agree that the Eclipse code is performing some nasty checks there I don't think I agree with the implication that the stacktrace created by the VM should change based on whether the method was inlined or not. I'm not sure what is mandated by the JVM spec but the stacktrace isn't going to be very useful for a developer debugging his program if the stacktrace changes depending on whether something got inlined or optimized away by the VM...

Here's what the Javadocs for Throwable.getStackTrace() say:

Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this throwable is permitted to return a zero-length array from this method.

On JDK 1.1 it was quite common to miss stack frames in a stack trace, but HotSpot is actually very good at creating a full stack trace even when it inlines methods. The CLR could certainly do better in this regard.

Bottom line is that the Eclipse code is very JVM specific and as far as I can tell it doesn't even serve any useful purpose.

Tuesday, 22 February 2005 21:20:05 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
Eclipse is Evil

While it's been possible to start up Eclipse with IKVM for a long time, editing a Java source didn't really work. Today I decided to look into the problem. It turned out to be caused by an IllegalStateException thrown from the following method in MarkerAnnotationPreferences.java:

/**
 * Checks correct access.
 * 
 * @throws IllegalStateException if not called by {@link EditorsUI}
 * @since 3.0
 */
private static void checkAccess() throws IllegalStateException {
  StackTraceElement[] elements=  new Throwable().getStackTrace();
  if (!(elements[2].getClassName().equals(EditorsUI.class.getName())
      || elements[3].getClassName().equals(EditorsUI.class.getName())))
      throw new IllegalStateException();
}

It looks at the stack trace that the Throwable produces to ascertain if it was called by the correct method. This is obvious not very robust (as is born out by the fact that it checks two different slots in the array).

The calling method in EditorsUI.java is:

public static void useAnnotationsPreferencePage(IPreferenceStore store) {
  MarkerAnnotationPreferences.useAnnotationsPreferencePage(store);
}

A perfect candidate for inlining! Which the CLR does, of course. So the EditorsUI class didn't appear in the stack trace at all, causing checkAccess() to fail.

For the time being I added a workaround to IKVM to disable inlining for all methods in classes named org.eclipse.ui.editors.text.EditorsUI, but that's obviously a disgusting hack.

Tuesday, 22 February 2005 13:49:56 (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
# Friday, 18 February 2005
Snapshot

Mostly bug fixing and a couple of work arounds for bugs in the CLR and Mono.

Changes:

  • Sync'ed with GNU Classpath cvs.
  • Fixed bug in ClassLoaderWrapper that caused exception when defining the ModuleBuilder if the first class loader to define a class had a toString() representation that contained characters that are illegal in an assembly name.
  • Changed System.identityHashCode implementation to use non-virtual call to Object.GetHashCode instead of RuntimeHelpers.GetHashCode, to work around .NET runtime bug.
  • Fixed reflection to support modifying final instance fields (as per JSR-133).
  • Added optional verbose cast failure messages (set the IKVM_VERBOSE_CAST environment variable to enable this).
  • Fixed unloadable type support in native method signatures.
  • Changed handling of delegate types that have unsupported types in method signature (inner interface is no longer generated). This fixes bug 1119575.
  • Added -enabletls option to ikvmc to automagically add ThreadStaticAttribute to fields starting with __tls_
  • Changed IKVM specific Classpath methods to use __tls_ fields instead of LocalDataStoreSlot. This improves performance, but also works around a bug in the CLR relating to AppDomain shutdown and a GC bug in Mono on Windows.
  • Added workaround for Mono bug in GCHandle.IsAllocated.
  • Fixed implicit interface downcasting (which is sometimes required due to a quirk in the JVM spec) to throw IncompatibleClassChange instead of ClassCastException.
  • Fixed bug in argument globbing code that caused command line of statically converted executables to start with the name of the executable (in args[0]) on unix.
  • Fixed bug that caused Thread.join() on main thread to hang.
  • Fixed JNI name mangling to support encoding Unicode and special characters correctly.
  • Fixed JavaException to not call String.Format on non-format strings.
  • Optimized VMThread.jniDetach to not do anything if a Java thread object was never created.

New snapshots: just the binaries and source plus binaries.

Friday, 18 February 2005 13:18:32 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Tuesday, 08 February 2005
Weird Bug

Jamie Cansdale reported a strange problem on the mailing list. His code ran successfully when run for the first time, but subsequent runs in the same process, but a different AppDomain failed with a ClassCastException.

He was kind enough to work with me to try and isolate the problem. So several hours and various private IKVM builds later, I was able to reproduce the root problem:

using System;
using System.Runtime.CompilerServices;
class Class1
{
  static void Main(string[] args)
  {
    RuntimeHelpers.GetHashCode(new Class1());
    if(AppDomain.CurrentDomain.FriendlyName != "2nd")
    {
      AppDomain dom = AppDomain.CreateDomain("2nd");
      dom.ExecuteAssembly(typeof(Class1).Assembly.Location);
    }
  }
}

This code dies with a System.MissingMethodException! Yet another weird multi-AppDomain bug.

Fortunately, the work around is easy. Instead of using RuntimeHelpers.GetHashCode() to implement System.identityHashCode(), I've gone back to using some handcoded IL in map.xml to call System.Object.GetHashCode() non-virtually. This was also what I did on v1.0 of the CLR (where RuntimeHelpers.GetHashCode() didn't yet exist).

Tuesday, 08 February 2005 14:52:47 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Wednesday, 02 February 2005
New Snapshot

Lot's of changes, but the major one is that Java's primitive type byte is now mapped to System.Byte instead of System.SByte. This makes interoperability between Java and other .NET code much easier (since System.Byte is in the CLS), although you have to be a little careful because Java's byte is signed and System.Byte is unsigned.

Changes:

  • Changed assembly versions to 0.11.*
  • Sync'ed with GNU Classpath cvs.
  • Added hack to support new Classpath awt event model.
  • Changed mapping of Java primitive byte from System.SByte to System.Byte, to remove the need for ByteArrayHack and better/easier interop with CLS code.
  • Regenerated mscorlib.jar, System.jar and System.Xml.jar with new ikvmstub (to deal with the new byte <-> System.Byte mapping).
  • Added optional support for compiling GNU Classpath with ecj to the build script. NOTE: The ecj -1.5 option is used to generate 1.5 compatible class files, so you must set the IKVM_EXPERIMENTAL_JDK_5_0 environment variable prior to starting the build process. When ecj is used to compile GNU Classpath with the -1.4 option, the build will fail because the resulting assembly is not verifiable. This is because ikvmc doesn't currently handle the way ecj compiles Java 1.4 class literals when used in the invocation of a base class constructor (this obviously isn't a common scenario, but it will be supported in a future version).
  • Added partial support for the new Java 5 StringBuilder class.
  • Changed the ikvm.lang.CIL boxing/unboxing methods dealing with bytes to account for the changed mapping.
  • Deprecated ikvm.lang.ByteArrayHack (it now contains only a single cast method that "casts" from byte[] to byte[], it will be removed in a future version).
  • Added ugly workaround for return type covariance in the IResourceReader interface.
  • Cleaned up setting the thread group when attaching a native thread.
  • Fixed JNI direct buffer APIs to support all types of java.nio.Buffer, not just ByteBuffer.
  • Implemented VMClassLoader.getPackages() to support enumerating packages defined by the bootstrap class loader. This is currently disabled on Mono due to a bug in Assembly.GetTypes() on Mono 1.0.5 and 1.1.3.
  • Implemented new stack walking mechanism that fully supports skipping over reflection and native stack frames.
  • Changed reflection to use new stack walking mechanism.
  • Changed native library loading to use new stack walking mechanism.
  • Fixed ikvmstub to return error value if it fails.
  • Added optional support to the build script to build a AMD64 version of JVM.DLL.
  • Fixed DynamicInvokeVirtual to actually do a virtual method invocation, instead of a non-virtual invocation.
  • Collapsed TypeWrapper.TypeAsParameterType and TypeWrapper.TypeAsFieldType into a single new property TypeWrapper.TypeAsSignatureType.
  • Fixed JNI_CreateJavaVM to support all valid JNI versions.
  • Fixed JNI DestroyJavaVM to return success when "destroying" the VM (even though -- like Sun -- we don't support actually destroying the VM).
  • Fixed JNI DetachCurrentThread to return success when detaching an already detached thread.
  • Fixed JNI FindClass to reject class names with dots and added support for signature format class names (e.g. [Ljava/lang/Object;), it also throws NoClassDefFoundError now instead of ClassNotFoundException.
  • Made some minor tweaks to JNI local ref allocation algorithms.
  • Changed reflective non-virtual method invocation to do a virtual invocation when invoking interfaces methods (for compatibility with Sun) and to use the regular reflection code path when invoking non-virtual methods or virtual methods that are guaranteed not to be overridden.
  • FieldWrapper.EmitGet/EmitSet and MethodWrapper.EmitCall[virt] no longer convert the field/return value from SignatureType to StackType, this is now left to the caller.
  • Fixed regression that could cause TypeWrapper constructor to try to construct a Class object for unloadable types (and this could result in an exception when an unloadable array type was constructed).
  • Renamed method TypeWrapper.EmitConvParameterToStackType to TypeWrapper.EmitConvSignatureTypeToStackType
  • Renamed method TypeWrapper.EmitConvStackToParameterType to TypeWrapper.EmitConvStackTypeToSignatureType.
  • Fixed native method invocation stubs to handle ghost types correctly.
  • Fixed reflection on .NET types to report Sealed and Abstract types as abstract only (the final abstract combination isn't legal in Java).
  • Improved handling of clashing method names for private interface methods.
  • Improved generation of base type method "hiders" for remapped types to support additional method overloads on Whidbey.

New snapshots: just the binaries and source plus binaries.

Wednesday, 02 February 2005 16:40:19 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]