# Thursday, February 28, 2008
« New Development Snapshot | Main | IKVM 0.36 Update 1 Release Candidate 5 »
IKVM 0.36 Update 1 Release Candidate 4

More fixes and a couple of optimizations. The bytecode optimizations and the removal of assert statements resulted in IKVM.OpenJDK.ClassLibrary.dll actually becoming smaller for once:

Version IKVM.OpenJDK.ClassLibrary.dll size
0.36.0.5         26,808,320
0.36.0.9 26,697,728


The size difference is about evenly split between the bytecode optimizations and the assert statement removal.

The ikvmc option to remove assert statements is a bit of a cheat, but it turns out that in at least one case (java.util.BitSet) the assertions significantly affect performance (even when they are disabled) on .NET. This is the result of the CLR JIT not optimizing them away whereas HotSpot completely removes them when assertions aren't enabled. Given that this was affecting a real world scenario for an ikvm user I decided to add this option and compile the core class library with it. The option will only remove assert statements that it recognizes (i.e. the example code pattern mentioned in appendix IV of the assert spec).

Changes:

  • Changed version to 0.36.0.9.
  • Optimized codegen for lcmp, fcmp<x>, dcmp<x> and shift opcodes.
  • Added support to Class.forName() for loading Java types with assembly qualified type names.
  • Implemented field/method/parameter annotation support for .NET types.
  • Added workaround for .NET 1.1 bug in Directory.CreateDirectory(). (bug #1902154)
  • Added -removeassertions optimization option to ikvmc.
  • Added -removeassertions to IKVM.OpenJDK.ClassLibrary.dll build.
  • Fixed JVM_CreateJavaVM to initialize the class library.

Binaries available here: ikvmbin-0.36.0.9.zip
Sources (+ binaries):ikvm-0.36.0.9.zip

Thursday, February 28, 2008 8:01:31 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [4]
Friday, February 29, 2008 4:24:48 PM (W. Europe Standard Time, UTC+01:00)
The Binaries in ikvm-0.36.0.9.zip (source) distributions are "signed" .. Ussually they are not. Can a the source package be regenerated with unsigned binaries?
Douglas Miles
Friday, February 29, 2008 4:34:10 PM (W. Europe Standard Time, UTC+01:00)
The binaries in the source zip are always the same as the ones in the binaries only zip.

If you want binaries that aren't strong named, download the classpath & openjdk source zips from SourceForge and do a "nant clean" followed by "nant -t:net-1.1"
Jeroen Frijters
Thursday, March 13, 2008 9:28:44 PM (W. Europe Standard Time, UTC+01:00)
First let me say that it's so nice that you've added field/method annotation support in this update, but now I have a question on that support. How would one go about using a bridged java annotation from c#? For instance:

public @interface MyAnnotationList {
MyAnnotation[] value();
}

In Java, one could simply call:

@MyAnnotationList({
@MyAnnotation(id="item1"),
@MyAnnotation(id= "item2")
}

But you can't accomplish the same thing with c#, which gives you an error if you try something like:

[MyAnnotationList([MyAnnotation(id="item1")],[MyAnnotation(id="item2")])]

Is there a bridging way to accomplish this result? Or is it just a limitation in the ikvm/c# bridging? The bridging doesn't seem to work for this sort of annotation.

And once again, thanks for adding the annotation bridging for fields and method! Very cool!

Johan
Johan Proust
Friday, March 14, 2008 6:32:03 AM (W. Europe Standard Time, UTC+01:00)
This is an area where .NET attributes and Java annotations differ. There is no official support in IKVM for applying these types of nested annotations, but if you're wiling to depend on an IKVM implementation detail (meaning that it might change in the future) you could use this:

[MyAnnotationList(new object[] {
(byte)'@', "MyAnnotationList",
"value", new object[] { (byte)'[',
new object[] { (byte)'@', "MyAnnotation", "id", "item1" },
new object[] { (byte)'@', "MyAnnotation", "id", "item2" }
}
})]

Note that the type names have to be assembly qualified type names, if they aren't in the assembly where they are used (or an assembly it directly references).

Here's a comment from runtime/attribute.cs that describes the structure:

// element_value encoding:
// primitives:
// boxed values
// string:
// string
// enum:
// new object[] { (byte)'e', "<EnumType>", "<enumvalue>" }
// class:
// new object[] { (byte)'c', "<Type>" }
// annotation:
// new object[] { (byte)'@', "<AnnotationType>", ("name", (element_value))* }
// array:
// new object[] { (byte)'[', (element_value)* }
Jeroen Frijters
Comments are closed.