serverside programs

Thu Sep 18 01:52:00 GMT 2003

> From: Erik Poupaert [mailto:erik.poupaert@skynet.be]
>> >>>Assuming no bugs in blackdown-jdk
>> I doubt there are such drastic bugs. 
For a recent version of the blackdown-jdk, I would be surprised. Some ancient JDKs
had misfeatures that might have accounted for it. It's very hard to guess at the
cause without more information. If the code relies heavily on finalization, I'd
be inclined to try more than one Java implementation.
It's hard to predict the memory consumption for gcj relative to a HotSpot-based VM.
But certainly the difference shouldn't be more than a factor of two or so either
way with default heap settings. I would guess that gcj tends to be smaller
under most conditions on Linux.
>> So, the fact that garbage collection is active, does not mean 
> that the code could not
> be full of memory leaks. A java serverside program can bring 
> down your machine (or
> else its own process), no sweat; and given the starting 
> footprint (tens of megabytes)
> and the speed at which numerous heap-based objects tend to 
> get created, way much
> easier than native programs.
I'm not sure what the starting footprint has to do with it. It seems to me that's also
a problem, but an unrelated one.
The garbage collector in gcj has a facility for telling you why objects in the heap are
reachable. It's still on my list to get this properly hooked into the rest of gcj
(and possibly revised to make that easier).
>> I've replaced the java emailserver with (native) qmail; and 
> memory consumption hasn't
> budged since. In my opinion, gcj needs options to reduce 
> starting footprint
> drastically, and then an option that introduces more 
> predictable memory
> de-allocation. Otherwise how can we recommend writing 
> serverside applications like
> qmail in Java to other people?
>I think you're inherently better off with Java here. I suspect you just ran into
either a buggy Java program or a gcj bug here. In C/C++ with new/delete
or malloc/free, there are two distinct ways to run out of memory:
1) Forget to delete objects.
2) Build data structures that keep growing.
In Java, (2) is really your only option, and it tends to be a bit harder to do than (1),
though it's clearly not terribly difficult either. Admittedly, bugs/misfeatures in the memory
management system are inherently a bit more likely with Java at the moment.
Hans