Notes to self

Today I discovered that Google has built a little J2ME application that you can download for free to your mobile phone, that let's you check your GMail on the phone. Before this application, if you wanted to check your e-mail on your phone, your only options were to void the GMail interface and use POP (if your phone supports that) or use the mobile version of their GMail web application. Both of these options have their individual problems.

POP is slow as spitand you don't get the GMail interface, you find that you'll be downloading all the mails that you already read on your PC, just to check your inbox, and you don't get the searching or any of the other cool features that make GMail, GMail.

The mobile version wasn't much of a celebration either, though I found it to be better than POP. The first issue with using this is that no matter what you click on, you will have to wait for a new page to load. You only check your email like this if you really, really, need to, and can muster the patience needed to watch oil dry.

Gleefully thinking that this little GMail gem would all of the above problems, and then some, I swiftly pointed my mobile browser to http://gmail.com/app and downloaded the application. The rest is a story of disappointing results.

It turned out that I had downloaded whineware.

whine·ware |(h)wīnˌwe(ə)r|
noun, Computing
software that is constantly complaining, or produce an unnecessary high amount of error messages and alerts, or complain about trivial conditions.

The adventure of using the GMail application for Mobiles started when I was on my merry (it was raining) way home and stopped by the shopping mall. I wanted to buy a new pair of pants but that is besides the story. At the mall, I got the idea to check my email so I could try out this GMail application, and I promptly booted it up. It starts by telling me that it needs a dataconnection. I have a dataconnection, but fair enough, I though, perhaps this was an on-first-start thing or something. After OK'ing the dataconnection alert box, I was unsurprisingly greeted with a login screen and I typed in my GMail credentials. My password is fairly involved and takes about a minute to punch in on the phone number keys, so part of my hopes for the application was that it, unlike the mobile version of web-gmail, would now be remembering my password for a fairly long time. After meticulously entering my credentials and pressing the login button, I was greeted with yet another dataconnection alert. Now it starts to get a little suspicious. Even on my new W980, the 3G network can be very flaky; going on an off all the time. This isn't a problem for the built-in mobile webbrowser, because it can just fall back on GSM - it sure is a great deal slower, but at least I'm making progress. The Opera Mini browser, which is built on the same Java runtime as the GMail application, is able to fall back on GSM as well, so there is just no excuse for making 3G, or any other dataconnection (like EDGE and greater) a hard requirement.

But I play along for a little while longer, and relocate to a better spot inside the mall with better 3G coverage. The connectively alerts disappear and I am graced with entrance to the Kingdom of my Inbox. That is, after I'm told that a password of zero length did not match with my username and that I have to enter it, again, which I do, for another full minute, or something like that. So then I finally get to my inbox and I can see that (yay!) I've got a new mail. I toy around with the interface of my inbox for a little while - it is quite snappy and responsive - and I click on that unread e-mail I got. Fooled again, the ugly face of that zero-length-password-no-good alert turns up again. This time I've had it. I am not typing in my password for the fourth time in what must have been 10 to 15, maybe 20 minutes. I close the application and promptly delete it in spite.

I'm a software developer by trade. It is not uncommon for me to spend the majority of my working hours looking at, analysing and debuging error messages. I do not need this kind of complaining from programs I use in my own time, and I certainly do not need the act of checking my mail to be an uphill struggle.

After this experience, I decided that checking mail could wait till I got home proper, and that it wasn't really that important.

So, Google releases a browser called Google Chrome. They use webkit as their rendering engine (good choice, IMHO) and their own V8 JavaScript engine.

This JavaScript engine is clamed to be very fast - as in, we're-smoking-everything-out-there fast - due to some clever type-inference, native JITing and aggresive garbage collection.

Bold claim - people want to verify this, and the most acclaimed JavaScript benchmark is the SunSpider benchmark, hosted on webkit.org.

I guess the rest is history

Now I only wonder how Opera will respond. They got a brand new JavaScript engine built for Kestrel, but sadly this part seems to get its arse handed to it by all of the next-gen JS-VMs; SquerrilFish, TraceMoney and now V8. The good news, though, is that V8 is released under a BSD license which makes it completely legal for Opera to just* yank out their existing part and replace it with V8.

*Only requires rewriting large parts of their JS intergration layer, which in turn might cause a hard reboot on their DragonFly project. But then again, you'd be foolish to expect a free lunch here.

PS. 'Case you're really craving some SunSpider numbers, this guy got some: http://forum.beyond3d.com/showpost.php?s=bdf3fd0c593033d8854848a2f5b11798&p=1211843&postcount=15

EDIT:

John Resig of jQuery fame posted a much more complete and thorough performance analysis: http://ejohn.org/blog/javascript-performance-rundown/

The majority of the visitors to this blog, I just noticed, come here because they are interested in my permgen saga:

1. Good Riddance, PermGen OutOfMemoryError!
   
2. PermGen Strikes Back!
   
3. Return of the PermGen
   

The last installment concluded with newfound hope in the JDK6 profiling tools and a promise to post back as more knowledge was uncovered. Well... that was a while ago.

So, why haven't I spent time blogging about all of the exciting findings I must have made along my quest to solve this problem, since the 29th of September, 2007? The answer is simple: I have not spent any time at all on this problem. The reason for this lack of effort is simple: permgens have not been a problem to me since about that time.

To properly explain what has happened, let me draw a parallel to writing code - multi-threaded code, to be presice: What is the primary concern in multi-threaded/concurrent code? Shared mutable state. The easiest way to solve this problem? Do not share state, or make shared state immutable.

Neither of these proposed solutions actually solve the problem of shared mutable state. Instead they remove it; make the problem moot - a non-issue.

I have not solved the permgen problem; I have made it moot. Well, the operations department have made it moot and I have been cheering from the side-line.

The Moot Permgen:

Recall the original problem: every so often we redeploy a Java web application on our application servers, without restarting said servers. An intricate object graph prevents the old class files from being unloaded, this equates to a memory leak in the permanent generation of the JVM that eventually causes the server to die with an OutOfMemoryError.

The thing that gets the hair ball rolling here, is the deployment without restarting the server. To make this problem moot, all we have to do is to always restart the server every time we deploy an application.

Simple, right?

It's like when you go to the doctor and say "It hurts when I do this" and the doctor says "Well, don't do that." Same exact thing. Deployment without a restart: Just stop it!

The Other Way around the problem:

We basically changed the way we deploy applications. Not in a big way, just some small adjustments.

First and foremost, we don't deploy anything without restarting the server - but you already knew that.

Second, we deploy less stuff on our servers - the fewer apps you run on a server, the faster it'll restart. Preferably, we would only run one application per JVM- this way, the restartes would only affect a single application.

Lastly, we're moving our production systems to load-balanced setups. When an application is running on two (or more) servers behind a load-balancer, then restarting a server won't incur any down-time.

It's not rocket science. It's a practical and workable way to simply avoid having to deal with the dreaded OutOfMemoryError: permgen.

It seems that lots of people are experiencing their Eclipse IDE crashing more or less randomly on thei 64-bit Linux systems.

However, it seems that adding this:

-XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/DataTreeNode,forwardDeltaWith

To your eclipse.ini fixes the issue, for some reason.

EDIT:

After installing some plugins, my Eclipse started crashing again. That's the bad part. The good part is that you can see in the generated hs_err_* file exactly which method the JIT compiler was groking when HotSpot crashed. This lead me to add another line to my eclipse.ini:

-XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding,<init>

And that seems to have solved the crashes... again.

As promised yesterday, version 0.0.4 of Fabric has been released.

Here's a direct link to the news item:
https://savannah.nongnu.org/forum/forum.php?forum_id=5233