# Monday, 16 February 2004
« New Snapshot | Main | F.A.Q. »
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] Tracked by:
"FREE POKER ONLINE" (FREE POKER ONLINE) [Trackback]

Tuesday, 17 February 2004 20:24:05 (W. Europe Standard Time, UTC+01:00)
I just noticed that the FAQ entry for ikvmc is outdated - it says that "in the future" it will be able to compile Java applications and libraries to .NET assemblies, when in fact it can do this extremely well already (so much so that I've never felt the need to even try running ikvm.exe)

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 ;)
Stuart
Name
E-mail
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)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview