# Tuesday, March 17, 2009
« New Development Snapshot | Main | New Development Snapshot -- Help Needed »
New Development Snapshot

One major change: I rewrote exception handling to store exception state in java.lang.Throwable (for non-.NET exceptions) instead of using a weak map. I never got around to doing that earlier, because the overhead of exceptions on the CLR is such that the weak map didn't contribute significantly, but on Mono the situation was very different, as it turns out the weap map was very slow there and exception handling is much faster. Anyway, the result is that on Mono a particular microbenchmark went from 40 seconds to less than a second. On the CLR the performance is also a little bit better, but still horrible.

If you use exceptions for control flow, make sure to override fillInStackTrace (simply "return this") as this saves a lot of time in collecting the stack trace. On previous versions of IKVM this sometimes didn't help, but now it always does.


  • Rewrote exception handling.
  • Moved PDB generating code (used by IKVM.Reflection.Emit.dll) into a separate assembly (IKVM.PdbWriter.dll) to work around missing ISymWrapper.dll on Mono.
  • Made java.lang.Object and java.lang.StackTraceElement serializable (in the .NET sense).
  • Added workaround for Mono bug (Type.IsGenericTypeDefinition throws for non-MonoType types).
  • Fixed ikvm.extensions.ExtensionMethods.printStackTrace() to unmap the exception after printing the stack trace.
  • Volker implemented a couple more AWT graphics functions.

As always with a development snapshot, don't use this in production, but please do try it out and let me know about it. The sources are available in cvs and the binaries here: ikvmbin-0.39.3363.zip

Tuesday, March 17, 2009 7:10:27 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
Monday, March 23, 2009 6:04:38 PM (W. Europe Standard Time, UTC+01:00)
I've been working with 3358 for the past week or so. It's giving me a null pointer exception deserializing an object coming off an object input stream. Today I tried compiling the same code using your 3363 release. However, 3363 gives a compiler error when trying to compile the code. I'll post the error below.

This same code compiles cleanly on 3358 and runs reasonably well. At least up to the point where it tries to deserialize one of my objects. Surprisingly, it doesn't complain when it serializes the object to send to my Java server. Only when it deserializes it on the way back to the client. It's also worth pointing out that some objects get deserialized normally, but this particular object blows up every time. Any ideas?

joseph@lindev:~/tmp/cvs/ControllerConnectorC#$ make
++ Building DssClientLibrary.dll
mono /home/joseph/Work/lib/ikvm-0.39.3363/bin/ikvmc.exe -target:library -out:DssClientLibrary.dll DssClientLibrary.jar -r:/home/joseph/Work/lib/ikvm-0.39.3363/bin/IKVM.OpenJDK.Core.dll -r:/home/joseph/Work/lib/ikvm-0.39.3363/bin/IKVM.OpenJDK.SwingAWT.dll
System.ArgumentOutOfRangeException: Argument is out of range.
Parameter name: imageFileName
at IKVM.Reflection.Emit.Writer.ModuleWriter.WriteModule (System.String directory, System.Reflection.StrongNameKeyPair keyPair, IKVM.Reflection.Emit.ModuleBuilder moduleBuilder, PEFileKinds fileKind, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine, IKVM.Reflection.Emit.Writer.ByteBuffer versionInfoData, Int32 entryPointToken) [0x00000]
at IKVM.Reflection.Emit.AssemblyBuilder.Save (System.String assemblyFileName, PortableExecutableKinds portableExecutableKind, ImageFileMachine imageFileMachine) [0x00000]
at IKVM.Internal.CompilerClassLoader.Save () [0x00000]
at IKVM.Internal.CompilerClassLoader.Compile (System.Collections.Generic.List`1 optionsList) [0x00000]
at IkvmcCompiler.Main (System.String[] args) [0x00000]
make: *** [DssClientLibrary.dll] Error 1
Joseph Dixon
Monday, March 23, 2009 6:19:53 PM (W. Europe Standard Time, UTC+01:00)
Please post such issues to the mailing list.
Friday, May 1, 2009 4:27:29 PM (W. Europe Daylight Time, UTC+02:00)
"If you use exceptions for control flow, make sure to override fillInStackTrace (simply "return this") as this saves a lot of time in collecting the stack trace."

Good advice on the JVM, too.
Comments are closed.