# Friday, 11 May 2007
« Custom Attribute Annotations | Main | Case Studies »
Merging the First OpenJDK Code and Another x64 CLR Bug

While working on integrating Sun's recently GPLed code to parse and toString floats and doubles (so that this long standing IKVM bug can finally be fixed) I ran into another x64 CLR bug, this time in the JIT. It was a little bit disturbing to see a Double.parseDouble() test fail with the Sun code that previously worked with my lame and hacked up parsing code, but fortunately the workaround was easy. The IKVM bytecode compiler now obfuscates any -0.0 literals it encounters to prevent the x64 JIT from "optimizing" them.

On a more general note, I haven't yet figured out how to go about integrating the whole of OpenJDK, but I have discovered it'll be quite a bit of work. For every class that uses native code to interface with the VM I'll have to decide whether to implement the existing native methods in C#, implement them in map.xml or rewrite the class to add IKVM specific code. Each option has different trade-offs, for example while it sucks to fork a class due to the added work of merging in changes, adding the required IKVM specific modifications inline is often the cleanest and most efficient way of implementing the required functionality.

I think I'm going to dip my toe into the water by changing my java.lang.reflect.* classes, which are currently modified versions of the GNU Classpath classes, into versions derived from the Sun code.

One final note. The OpenJDK is supposedly licensed under the GPL + "Classpath" exception, but the license text says that only files that explicitly opt-in to the "Classpath" exception are covered by the exception. That implies that I'll have to examine each source file to make sure it is covered, before including it with IKVM.

Friday, 11 May 2007 16:17:15 (W. Europe Daylight Time, UTC+02:00)  #    Comments [3]
Friday, 11 May 2007 19:41:55 (W. Europe Daylight Time, UTC+02:00)
about your work of ntegrating the whole of OpenJDK and our 3 options. Could you provide more details? From what you write, it sounds like using aspectj to inject annotations could be useful. Codegeneration might also be useful?
Saturday, 12 May 2007 01:36:07 (W. Europe Daylight Time, UTC+02:00)
It's too bad that the Sun and Classpath code aren't compatible down to the native methods called by the pure Java code.

I figured that you'd go the "native methods in C#" route, so I'd be interested to know why you think that the "IKVM specific modifications" route is cleaner and more efficient (efficient in terms of performance or time to implement?).

By the way, have you ever considered switching IKVM from CVS to SVN on SourceForge? SVN is just so much nicer, especially when dealing with tags and branches (as you might want to do while experimenting with integrating the Sun code).
Thursday, 31 May 2007 20:20:48 (W. Europe Daylight Time, UTC+02:00)
The reason the Classpath and Sun VM interfaces differ is because it's only now that the Sun interface is accessible to Free implementations. Trying to match it prior to this would have been a horrible exercise in reverse engineering the interface, distributed over the multiple VMs Classpath supports. At the time, it was clearly better to create an interface that suited the current consumers of Classpath rather than Sun's interface, given that no-one really guessed that they would make it available under acceptable terms in the future.
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview