Change of Blog Technologies – moving from Java to LAMP

I am moving my Blog+Wiki to Movable Type. SnipSnap has served me well. It is Java based, which suits me fine, because I am a Java guy. I run several Linux boxes from my home, which are permanently Internet connected.
However I am planning to move overseas for a year with my family. We will be leasing our house, so I must find a new home for either my servers or my sites. I was quoted a cost of co-location of $200 per month per server, which for my two servers would be $4,800 for the year. I can move the sites to a shared Linux environment for $150 per year.
Doing so requires me to move my commercial software site http://simonsayssoftware.com.au and my non-commercial blog to LAMP technologies. So that’s what I am doing.
Hosting companies require those wishing to run Java to either use a dedicated server or co-locate. Why is that? In two words, the Virtual Machine. Java is plenty fast enough compared with PHP or Perl. The problem is the memory the VM consumes. On a shared environment, you need to use small amounts of resources, and then hand them back when you are done. The Java VM grows and rarely shrinks. I have never seen one shrink by more than a few percent. This is customisable but still very limited.
So, will Java always be a non-starter for the shared environments of hosting companies? There are two reasons for optimism.
Firstly, JDK5 introduces Class Data Sharing to Sun-based VMs. See http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html. Apple have been doing this for a while on OS X. See http://developer.apple.com/documentation/Java/Conceptual/Java141Development/index.html. Sun claims a saving per VM of at least 6MB.
Secondly, there is the Gnu gcj project, which provides Java compiled to native code. It does not use a Virtual Machine. See http://gcc.gnu.org/java/. This project is rapidly maturing. On Fedora Core 2, a whole stack of Java applications compiled with gcj are available, including ant and Tomcat. RedHat are the ones pushing hard for this. I remove these at the moment, because they are the wrong versions for my work and system-wide stuff gets confusing. Having had a read of some user experiences, it seems that it is still a bit raw. If it matures into a first-class Java implementation, then I think the way will be open to use Java on shared hosting environments.
The problem with Virtual Machines is that they generally do not hand back to the OS memory freed from the VM Heap after garbage collection. It depends on the application, but for an application using 100MB of RAM, free memory will be significant, and at times in the order of tens of megabytes. Gcj promises to solve this problem.