[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 18 10:38:51 2003 
Subject:RE: Comparing Garbage Collectors 
From:jclinton 
Volume-ID:1031218.06 

Hi Steve

It's an interesting comparison. A few years ago we re-wrote our =
Clementine client application in Java, which had started life as a =
Poplog/Pop-11 and ObjectClass application. This gave us an insight into =
the behaviour of Java and Pop-11, or at least the 2001 version of =
Pop-11, under similar circumstances. Both applications usually had heap =
sizes greater than 150Mb and our latest client uses a default maximum of =
256Mb (although the internal architectures are quite different and these =
figures don't represent any comparison of the way objects are =
represented).

A few things we noted:

1. The client has a fair degree of interactivity (e.g., dragging objects =
around on a canvas). In Poplog, garbage collection would cause the =
client to "lock" for a few seconds. We used the non-copying GC because =
the copying GC generally caused much greater paging and making the whole =
machine unresponsive. We initially noticed similar locking behaviour =
using the default settings in Sun's JVM. However, this was largely =
eliminated by using Java's incremental GC (-Xincgc option). Having an =
incremental or generational GC would have been useful in Poplog to try =
to avoid these long pauses.

2. We also noticed we could improve overall performance if we increased =
Java's "nursery" size (the area of memory where objects are first =
created). By increasing this to 4Mb from the default 600K, many =
operations that produce large numbers of short-lived objects (such as =
parsing XML) went 2-3 times faster. Again being able to tune Java's =
memory management behaviour was useful, although in this case it was an =
issue brought about by the additional memory management features.

3. When the maximum heap size is reached and new objects can't be =
created, Poplog generates a mishap that can be trapped -- you obviously =
have to be careful about what you do at that point but at least you can =
trap it. Due to threading issues, Java's OutOfMemoryError can't be =
trapped reliably. We monitor the System.err stream for text that =
represents an OutOfMemoryError and turn the memory monitor red but it's =
not always reliable.

4. A more serious issue with Sun's JVM is that if the machine's heap is =
used up before the max JVM heap size has been reached (i.e. if Java =
requests more heap and the OS refuses), the JVM just exits. This is =
rather unpleasant for the user whose application disappears on them, =
losing any unsaved work. To try to lower the chance of this happening, =
we override the user's maximum memory settings so that the JVM won't use =
more than 75% of the physical memory in their machine. I'm not aware of =
it happening in the field but right now this probably the most serious =
problem we've got with Java (or at least Sun's JVM).

5. On a more trivial basis, when Poplog GC'd, it put a custom cursor up. =
Java doesn't which is a pity as it is useful feedback to the user. We =
also found the pop_after_gc hook quite useful for checking memory =
behaviour. The closest thing we have in Java is to create a temporary =
object whose "finalize()" method (which is called when the object is =
GC'd) updates the memory stats. Unfortunately, not all Java GC types run =
the "finalize()" method so the actual memory usage isn't always =
reflected in the UI.

I guess the summary is that Java has greater flexibility in controlling =
the effect of memory management (short but frequent, infrequent but =
long, memory segment size etc.) than Poplog but applications built on =
Java can produce less effective feedback during GC and can be less =
robust when memory becomes tight.

Happy Christmas...

Julian


-----Original Message-----
From: Stephen Leach [mailto:steve@watchfield.com]
Sent: 17 December 2003 22:21
To: pop-forum@cs.bham.ac.uk
Subject: Comparing Garbage Collectors


Hi all,

Well I've been doing serious programming in Java for a couple of years
now.  My current project uses the highly regarded IntelliJ IDEA=20
environment on my Mac OS X workstation.  I noticed that the heap was=20
getting fairly large, about 90Mb.  As I was about to take a break I
decided to invoke the garbage collector (just for fun).

To my amazement, this caused my Mac to buckle at the knees as if I=20
had asked it to do something difficult.  The cursor spun for a good
30 seconds and the entire user interface was unresponsive for perhaps
10-20 seconds.  I was quite surprised since my workstation has 900Mb=20
of RAM, has a 800Mhz PPC processor which, though far from top of the
range, should easily cope with this demand.

To double-check that my expectation was realistic I fired up my
lackluster Linux box and launched Poplog.  I then switched off the=20
copy-based garbage collector (probably unfavorable for Poplog)
and created a fairly messy data structure of 100Mb (exclusively
"full" data - no cheating with non-full data types.) =20

I then triggered a garbage collection which Poplog completed in=20
less than 6 seconds.  I messed around a bit further to see if I could
trip Poplog up but didn't succeed in getting the delay up to 6 seconds.
And, for comparison, this was on Pentium II (350Mhz) with 320Mb RAM.

I found this a very sobering observation.  Although the Java GC
is incremental and Poplog's is not, there are still plenty of=20
disruptive breaks in the IDE as the GC kicks in.

I can't easily account for this massive discrepancy in performance. =20
I presume, yet again, that John Gibson's work on the Poplog garbage=20
collector is the source of the difference.  But the difference is
so extreme that I can't quite believe any explanation. =20

Now one could argue that the performance of the garbage collector
isn't much of an issue in practice.  But when the IDE is running heaps
at +100Mb plus (and none of my applications execute in heaps in less
than +256Mb anyway) it is a key issue.=20

There no immediate conclusion to this post - except to wonder how the
heck I can get Poplog onto my Mac OS X system pronto!

--=20
Steve