Intelligent memory management in Java

Why should you worry about memory usage in Java? Because as much as memory is cheap, conserving it is still important. It would be stupid if Notepad (or KWrite) ate through 512Mb of memory before you’d opened a document… On the server side, if each of your users required 64Mb of session memory, you’d quickly run into performance issues when dealing with thousands of users.

So how can you conserve memory in Java. The first (and most obvious) way, is through the reference API: java.lang.ref. Using a SoftReference means that the object “behind” the reference can be garbage collected when memory is running low. Combined with what can be though of a lazy-loading, objects can be effectively cached in memory.

EoD SQL makes use of WeakReference’s to maintain == (identity) equality. A WeakReference will be valid until the object behind it is garbage collected. The garbage collection can take place as soon as no hard references to the object exist. This is important in EoD SQL, since if the calling code (application or web-app) doesn’t hold a reference to the object, how can it test for any kind of equality? To add to this point, EoD SQL may be dealing with very large volumes of data (since a database ResultSet may be millions of rows long), and holding hard-references may lead to OutOfMemory errors. Holding SoftReferences is also a bad idea, since working through a large ResultSet may lead to performance issues when many threads are working with similar sized ResultSets, and all of them or trying to keep the data in-memory.

For small objects, it is actually a good idea not to cache them in memory (with or without a hard-reference). Wherever possible, cheap objects should be short-lived, the eden-space garbage collector runs frequently and very quickly. Watch where you reference objects from! Lazy Loading is often a good idea, and can be strongly enhanced with Lazy Discarding (using a SoftReference).

For more information on how the garbage collector in Java works (and a bit of info on ClassLoading), take a look at the short presentation I made here.

Why classpath scanning is bad for you

It’s fairly popular in Java for frameworks, containers, and sometimes even scripting languages to do a classpath scan to find components, implementations and other interesting classes. Most people think nothing of this, except that it makes life easier (if sometimes a little slower). However, classpath scanning can be a very bad thing.

Most people seem to forget that Java no longer works with the classpath in the same way it used to. The classpath is simply used to define a bootstrap environment, from with the URLClassLoader can work. I have come across systems that don’t even have the full JRE deployed in their client environments, opting instead to load all their classes over the network, or sometimes even out of a database.

The classpath only takes into account the basic set of classes given to the VM. A lot of classpath scanners also assume that classes are only stored in either a JAR file or a Directory. This is not at all the fact, they could be stored in a Pack200 file, a tar.gz / tar.bz2 file, or even some file-format that you’ve never heard of.

Unfortunately the classpath is a badly abused structure. If you do need to “magically” find classes at runtime, look at either the ServiceLoader class, or into using ClassLoader.getResources.

EoD SQL 1.0 on the way (finally)

After months of hard work (on other projects), I’ve finally turned my attention to EoD SQL once again. The API has been stabilizing the past months with bits of work and attention from a few different people (myself included). There have been a few functionality changes (to correct early mistakes), but on the whole the API has come out with more power, and far better performance than ever before!

The primary things to look out for in the 1.0 release:

• Control over DataSet caching
  • Array based caching by default
  • NullCache implementation provided
• DataSet’s stay more connected
  • By making better use of the underlying ResultSet methods, connected DataSet’s almost never disconnect from the database
• A brand new tutorial that offers a quick and easy path to working with EoD SQL
• A generally more stable, faster, and much more mature API

The release will probably be made early next week, and will also include a series of new Unit Tests that work with Java DB (included with Java 6). This means that the Unit Tests will now be able to test more of EoD SQL than before.

Open Office to Netbeans for my Wedding

I’ve just written the first paragraph of my wedding speech (getting married next weekend, 2007-09-15) using Open Office. It’s generally a lovely writing tool, except I just discovered that it doesn’t have a “Select Current ATOM” shortcut. So, I’m switching to Netbeans to write the rest of the speech. What kind of IDE doesn’t have an “ALT-J” combination to select the current ATOM!