Wednesday, February 2, 2005

519.aspx

Java vs .NET, Microsoft vs SUN and other loaded development issues

This is not a happy post. You better skip reading this if you're a Java fan or otherwise don't feel like listening to my gripes Java.


There is one thing I love about programming for Microsoft platforms (client/server/web/PDA/…): Microsoft's online documentation is vastly superior to anything else out there. It used to be true of Borland and it is the reason I taught myself programming from the Turbo Pascal help and examples files. There are tons of example code available in the various SDKs, MSDN and other online forums. Microsoft knows that the success of Windows depends of a horde of happy developers spewing out solutions using easy to use tools like VB.


Being (sort of) open source, I would have expected Java to be even better. Not so. I am in in deep shit these days for a making a 3rd party solution work, that goes in production Sunday morning at 4am. Failure is not an option so I have to Make The Damn Thing Work. Easier said than done as the SUN Java Virtual Machine explodes below my butt leaving no trace. Now, I don't give up easily, so I have tried every trick I can think of to the SUN JVM log what makes it commit suicide:



  • use a class running in the JVM to redirect stderr to a file

  • redirect stderr/stdout to a file from my host using fredir()

  • use the JNI version 1.2 JNI options:


    • vfprintf

    • exit

    • abort

No way. It JVM kills the host process without logging anything or calling any of the callbacks.. A global try/catch doesn't catch any JNI errors so it's definitely the JVM that kills the host for some reason.


The official online documentation on java.sun.com regarding the corner stone of Java, the JVM, still contains refers to an ancient version of Java: This document is written from the perspective of 1.3.1 JVM on the Solaris (SPARC Platform Edition) on the subject of Garbage Collection. GC is, as the document states, the principal bottleneck in many solutions so I can't understand why they document it better. .NET from this point of view is nothing short but fantastic. MSDN and other Microsoft publications/sites are full of details on .NET Garbage Collections and how it works in version 1.0, 1.1 and the still to be published 2.0.


I was working on a critical server component last year and used Performance Monitor in Win2k3 to keep an eye on how various versions worked out. It covers all issues, including how much time is spent in Garbage Collection, memory usage etc. Use Process Explorer and you can see anything a process does.


Not so with the Java 1.4.2 bug I have been fighting the last few days. The JVM shuts down without leaving a trace; no errors to stderr, no logs to the HotSpot log file. It just silently commits suicide. After several sleepless nights, it looks like I hope we have found the problem. The JVM bombs without logging anything Garbage Collection if it is running low on memory. This JVM bug was fixed in version 1.3.1, 1.4.0 and 1.4.1 so I hope it is not still haunting us. Since it does not log any thing it's pretty much like hunting for the famous needle in the haystack. We will try a mix of Java GC and Java Performance settings tomorrow to see if it is possible to make it run for more than 5 minutes before crashing.


Reading the JVM options guide it is clear why Java runs a faster on Solaris than in wintel. Several of the tuning options are only available on Solaris and the other ones have different default values (>2MB for default new gen in Solaris but Intel is limited to 640kb, 32mb max new gen on SPARC, 2mb on Intel)


Don't get me wrong. Java is a neat language. C# copied all of it's cool features just like Java world copied the latest Microsoft features from the last millennium (jsp, data sets and transactions etc).


Time to get a grip on infant mortality and other nasty concepts before going to bed.

No comments:

Post a Comment