User:Brooke Vibber/Mono issues

I've been using Mono for a few internal tools for Wikimedia. Generally I like it but it feels a bit immature yet; if you're writing anything non-trivial it seems you've got a good chance of encountering a few bugs in the runtime and class library.

I have gotten good response from the Mono crew on these; isolating a test case, filing a good bugzilla report (perhaps with a patch!) and poking someone on IRC generally gets the job done in a reasonably timely fashion. The class library is reasonably easy to hack, so I've usually had good luck isolating problems and have often been able to provide a simple patch.

However tracking down bugs in the language environment is kind of a pain; it takes time away from what you're trying to accomplish yourself, and then you have to maintain a patched installation for a couple months until the next release... which you promptly have to patch for yet another bug.

I've also had issues with MonoDevelop, but that's another story. :)

For reference, here are the bugs directly impacting the code I've been working on so far:

Search

Mono bugs that have affected search (fixed in current releases):

• Flow analysis bug in switch statement -- code wrongly marked "unreachable"
  • Broke compilation of dotlucene
• Remoting server doesn't close HTTP connection
  • Broke XML-RPC interface for updates

Dump processing

Affecting page data dump processor (mostly fixed in SVN, after 1.1.9):

• DateTimeStyles.AdjustToUniversal ignored when UTC indicated by 'Z'
• DateTime.Parse applies timezone incorrectly around daylight saving time transition
  • I worked around these two by writing a special-purpose timestamp parser for what I needed.
• XmlTextWriter produces bogus output for UTF-16 surrogate characters
• XmlTextReader fails if Unicode surrogate pair straddles 1024-character boundary
  • These two are fundamental bugs in the class library; the patches are required for proper XML I/O if you will encounter characters outside the BMP.
• Can't write files past 2gb on AMD64 (x86_64)
  • Fundamental bug in the runtime; patch required to work with large files on 64-bit. Bug will affect any platform with 64-bit 'long' type.
• String.StartsWith() hangs with managed collation when strings differ by accent
  • This is a regression in the development branch of Mono
• XmlTextReader corrupts UTF-16 surrogate characters in strings
  • Another fundamental XML handling bug.

I'm moving the dump processing code from C# to Java for a number of reasons:

• Distribution
  • I need to provide this tool to end-users to work with dumps with a minimum of fuss. Downloading and installing Mono is a bit of fuss; patching Mono source for runtime bugs and recompiling it, more so. A Java VM is more likely to already be present and to be easy to install.
  • I'd hoped to use mkbundle; it mostly works on Linux, unless you have a different libc version... (d'oh)
  • mkbundle doesn't currently work on Mac OS X or Windows
• GUI frontend plans
  • Gtk# requires a Gtk+ install, is user-hostile on Mac OS X (X11)
  • SWF is hostile everywhere ;)
  • Don't want to write the GUI three times (SWF, Gtk#, Cocoa#)...
• Tools
  • Eclipse is a much more powerful and productive environment than MonoDevelop. (Translation: it doesn't crash as much! ;)
  • There's actually a debugger that works in Eclipse+Java...
• Bugs :(
  • I've hit seven bugs in Mono up there, four of them showstoppers that produce corrupted output on the current Mono release.
  • As a result I've spent many hours fixing Mono instead of working on my own code. It's great that I'm helping the Mono project to become more robust, but it's hurting my ability to deliver working code right now.
  • Discovering runtime bugs halfway through (or after) a 40 gigabyte data dump has meant a lot of delays getting said data dumps out. On my Java port I've so far discovered just one timezone-handling discrepancy between the Sun JDK and GCJ, which doesn't even affect my application once I got my timezone usage done correctly. Hopefully that's all I find. I'd hate to go to the trouble of switching again; to Python this time maybe? ;)

The Java version also seems to run a fair clip faster, but I need to test that again as I was having oddities with background file monitor daemons. If it really is 3x faster that's a neat plus. ;)

(One caveat with Java on GCJ 4.0.1 though is that memory usage is bad; it seems to grow the heap significantly. On the Sun JVM memory usage stays svelte.)