# Tuesday, 31 December 2002
2 min 30 sec

I figured out a way to lazily create the stack traces (only for ClassNotFoundException, but the principle applies to some of the other exceptions as well) and this enables me to get the improved performance without losing stack trace information. With a precompiled xerces implementation, Eclipse startup is now 2.5 minutes.

Details of what I did:

Previously, whenever an exception object was instantiated, a call to Throwable.fillInStackTrace was inserted, but when the exception is thrown this isn't needed (when the exception isn't thrown, but printStackTrace is called on it, the call to fillInStackTrace is needed). So the compiler now checks if the instruction following the exception constructor invocation is an athrow and if it is, it will not add the call to fillInStackTrace.

The above in itself wouldn't really help performance, because whenever an exception is caught, the full stack trace is computed (if it wasn't done before), so I added code to the compiler to detect that the exception handler didn't actually use the exception object (easy for code compiled with javac 1.1, because the first instruction of the catch block is pop, harder for code compiled with javac 1.4 or jikes, because it stores the exception in a local variable, even if it isn't used). If the compiler detects that the catch block discards the exception object, it will not emit a call to MapException (which in turn calls fillInStackTrace).

Tuesday, 31 December 2002 13:12:46 (W. Europe Standard Time, UTC+01:00)  #    Comments [1]
# Monday, 30 December 2002
Eclipse Startup Perf

A large part of the startup time of Eclipse is caused by the overhead of producing stack traces for the about 25.000 ClassNotFoundExceptions that are thrown during startup (a really lame design of the Java class loader causes it to throw multiple ClassNotFoundExceptions for each class that is loaded). Java and .NET exception handling differ sufficiently that I have to do a lot of processing to build a stack trace for each exception that is thrown, and this is pretty expensive. As a test I decided to disable stack trace generation for ClassNotFoundExceptions and this reduces Eclipse startup time to 3 minutes! Note that this isn't entirely comparable to the 7 minute figure from Saturday, because various other things have also changed.

An alternative optimization that I investigated, was to add a hack the ClassLoader and URLClassLoader to reuse the exception object in URLClassLoader instead of throwing a new one, this also saved a significant amount of time. I'm wondering how others feel about this optimization? It consists of two changes: 1)ClassLoader.loadClass() calls ClassLoader.findClassFast(String name, ClassNotFoundException e) which calls ClassLoader.findClass(), 2) URLClassLoader overrides findClassFast and does a check to see if it has been subclassed, if not it calls findClassImpl and passes it the exception object it got from loadClass, if it has been subclassed it call URLClassLoader.findClass which calls findClassImpl with null as the exception object.

We're not there yet, but progress is being made :-)

Monday, 30 December 2002 18:00:08 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
# Saturday, 28 December 2002
No Title

Have you tried the java.util.zip.ZipFile speedup patch? http://gcc.gnu.org/ml/java/2002-12/msg00288.html It made a huge difference in startup time for gij. [Mark Wielaard]

Just did. Startup (with the CVS explorer and a Java source open) went from 7:18 to 7:03, so it does help, but not enough ;-)

Saturday, 28 December 2002 17:29:40 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
No Title

Eclipse on .NET. Jeroen Frijters: I got Eclipse to run  I wonder if something like NGEN could be used to address the startup time issues. [Sam Ruby]

It should be possible to use ikvmc to compile the jars to .NET assemblies, at some point in the future I will probably look into this.

Saturday, 28 December 2002 16:57:46 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
Eclipse on .NET

I got Eclipse to run. Lot's of stuff still doesn't work, but CVS browsing and Java file editing works. Startup is very slow (a couple of minutes), but once the classes are loaded performance is OK.

Screenshot. Exception log.

Instructions:

  • Download the ikvm.net binaries
  • Install Eclipse
  • cd \eclipse
  • \ikvm\bin\ikvm -Djava.version=1.3 -cp startup.jar -Xbootclasspath:plugins\org.apache.xerces_4.0.7\xercesImpl.jar;plugins\org.apache.xerces_4.0.7\xmlParserAPIs.jar org.eclipse.core.launcher.Main -os win32 -ws win32 -arch x86 -install file:C:/eclipse/
  • Ignore the "System.UnauthorizedAccessException: Access to the path "d:\eclipse" is denied." exceptions

Updated the binaries and source snaphots.

Saturday, 28 December 2002 13:39:24 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
# Thursday, 19 December 2002
SourceForge

I set up a SourceForge project. I checked in all the code and created a mailing list. Since I'm a total SourceForge newby, any comments are appreciated.

I expect the mailing list to be very low traffic, so if you're at all interested in following IKVM.NET, please subscribe.

BTW, I dropped the first dot from the name. It's now IKVM.NET.

Thursday, 19 December 2002 09:07:54 (W. Europe Standard Time, UTC+01:00)  #    Comments [2]
# Tuesday, 17 December 2002
Back home and logs

I'm back from Bonaire. Many things to do, and I'm not sure when there will be progress.

While browsing the web server logs, I found an interesting item:
tide72.microsoft.com using Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.0.3215; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 1.2.21120)

Someone inside Microsoft running Whidbey on Longhorn? Not very surprising of course, but the fact the version number is 1.2 puzzles me. It has been generally assumed that Whidbey would be 2.0.

I'm looking forward to beta testing that stuff... On a related note, anybody have any idea when the next PDC will be?

Tuesday, 17 December 2002 12:48:01 (W. Europe Standard Time, UTC+01:00)  #    Comments [5]
# Friday, 13 December 2002
temporarily out of order

The server hosting www.frijters.net seems to be having problems. For the time being the source and binaries can be downloaded here: source, binaries.

UPDATE: server is back up again.

Friday, 13 December 2002 19:37:56 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
protected

Interesting post by Chris Daly on the advanced-dotnet list today. He questions the C# language spec, which says that the following is illegal:

public class A
{
protected int x;
}
public class B: A
{
static void F(A a, B b) {
a.x = 1; // Error, must access through instance of B
b.x = 1; // Ok
}

The equivalent Java is legal. When I statically compile the Java equivalent of A and B into two different assemblies, to resulting B.dll is unverifiable. It's not just a C# language issue, the CLR restricts access to protected members in this way. When both types are compiled into the same assembly there is no problem, because protected is compiled as famorassem so any type in the assembly already has access (this is needed because protected also implies package access, which has no CLR equivalent).

I wonder if a work around is required.

UPDATE: I wasn't quite awake yet. Of course, the reason that the above code works in Java is because protected implies package access, it has nothing to do with the protectness of the field. When you move A and B into different packages, javac fails with the same error as the C# compiler.

Friday, 13 December 2002 14:32:21 (W. Europe Standard Time, UTC+01:00)  #    Comments [0]
# Tuesday, 10 December 2002
No Title
I did some debugging last night to try and figure out where the random NullReferenceExceptions come from when running the SWT samples. I couldn't pinpoint anything (adding Console.WriteLines completely changed the behavior :-(), but when I tried running the exe under the 1.1 beta CLR the problem didn't occur, so naturally, now I'm beginning to wonder whether it is actually caused by a CLR bug...
Tuesday, 10 December 2002 16:25:19 (W. Europe Standard Time, UTC+01:00)  #    Comments [3]