A java app bogs down terribly with Ubuntu

[nbob]

Hi. I am running Ubuntu 9.4 and Windows XP. I like to play card games on pogo sometimes. It never fails that my whole system seems to come screeching to a halt after I've been playing awhile. I am also streaming music at the same time. Maybe java is to blame, or maybe Ubuntu.

Has anyone else experienced this? Ive tried clearing my cache, installing Intel graphics drivers, shutting down startup applications, etc... Nothing seems to work. I'm willing to try anything at this point.

[Thrillhouse]

Are both the card game and streaming music apps running java? If so, it sounds like one of them has a memory leak. Try running them independently and see if you can narrow down which one it is.

[Rubberman]

Java uses a mark-and-sweep non-deterministic garbage collector. What that means is that when it is collecting garbage your java application is on hold until done. This can take a lot of time because it has to look at all the memory used by the java application to determine if it is reachable anywhere, marks it for deletion if not, and then goes back and deallocates the marked segments. Finally, it moves (compacts) all the accessible memory which requires that all references to it are fixed up to point to the new location. This is a very "expensive" operation in CPU terms. If your application has used enough memory that some portion of it has been swapped to disc, then this time increases exponentially. I've seen java applications come to a literal screeching halt for over 5 minutes at a time in such situations.

So, what is the solution?

1. More memory so the application data isn't swapped to disc as often.
2. More and faster CPU's.
3. Patience.

I will never deliver a mission-critical enterprise application implemented with java for just these reasons. I have written deterministic garbage collectors for C++ applications - not a simple thing, to be sure, but the result is a fast system that never needs to worry about dangling pointers and memory leaks, yet performs well enough for near real time applications on a 24x365 basis.

[Thrillhouse]

If your application has used enough memory that some portion of it has been swapped to disc, then this time increases exponentially. I've seen java applications come to a literal screeching halt for over 5 minutes at a time in such situations.

This would almost never happen in a Java application. First off, a Java process will only run as long as it has enough memory to do so. When it reaches its limit, it will throw an OutOfMemoryError exception. The default limit in the Sun JVM is 64M (last I checked). You can specify the maximum heap size possible in the call to Java and expand it to a ridiculously large number but most Java apps I've seen don't do this (the largest I've seen is 1GB and that was on a production machine with 128 GB RAM). So, the only way for spooling to occur is for the user to specify a maximum that is so large, the operating system has to resort to Virtual Memory. And even in that case, the program would probably quickly terminate (although I have never seen it). All that being said, you have to be a pretty bad programmer to have memory leaks in Java. Unless someone was running some whacked-out version of the JVM, they would not observe the problem you describe.

I, for one, prefer the perks/convenience of automatic memory management and pointer recalculation over having to worry about a programmer who may or may not know how to manage his/her own memory.

[Rubberman]

This would almost never happen in a Java application. First off, a Java process will only run as long as it has enough memory to do so. When it reaches its limit, it will throw an OutOfMemoryError exception. The default limit in the Sun JVM is 64M (last I checked). You can specify the maximum heap size possible in the call to Java and expand it to a ridiculously large number but most Java apps I've seen don't do this (the largest I've seen is 1GB and that was on a production machine with 128 GB RAM). So, the only way for spooling to occur is for the user to specify a maximum that is so large, the operating system has to resort to Virtual Memory. And even in that case, the program would probably quickly terminate (although I have never seen it). All that being said, you have to be a pretty bad programmer to have memory leaks in Java. Unless someone was running some whacked-out version of the JVM, they would not observe the problem you describe.

I, for one, prefer the perks/convenience of automatic memory management and pointer recalculation over having to worry about a programmer who may or may not know how to manage his/her own memory.

Sorry, but I have seen this happen, and not infrequently. A lot of people up the maximum memory available to the JVM for many applications. Newer java versions have improved the memory management functions so you can have different pools for different parts of your application, and can gc them when convenient, but it's not simple to use them, so most java apps use the default gc and memory management behavior. In my experience, seeing java applications use over 500mb of ram is not entirely unusual. Also, if his is a memory constrained system, even 128mb might cause it to hit the swapper.

Unfortunately it got broken, but I used to have a nice Java coffee mug given to me by Jim Gosling at an Embedded Systems Conference in Boston back in the early-mid 90's just when they first released java to the wild.

Finally, the garbage collection functions still put the application on hold, and this will absolutely pause the application for an indeterminate period of time, resulting in a commonly observed "stutter" in the application's behaviour and performance at times.