Hello Michael,
MEM>i think the jvm/jdk has a big leak with one or more of the
MEM>classes used.
I'm running the Blackdown JDK (1.2-RC3, with sunwjit and native threads) here
with very good results. I have only one (non-trivial) application running, and
it doesn't show your problem. It uses sockets (although only two permanent
connections) with a steady throughput of around 1 kb/s and is quite graphics
intensive at the same time.
I have built a memory counter into it (displaying the free memory every 1/10
s), and the counter is constantly decreasing from around 3600 kb free to 2800
kb free - then the GC kicks in and the available memory goes back to 3600.
This whole process of spending and realocating 800 kb of memory takes between
1 and 2 seconds.
The values displayed by "top" are absolutely constant. I can run the
application for hours (with the memory usage as described above) and the
"SIZE" value will not increase at all (as long as I don't tell the program to
do anything to increase its amount of "real" working data, of course).
Granted, I have done quite a few optimizations in the application to reduce
the usage of "new", but obviously it recycles quite a bit of memory (800 K per
1 or 2 seconds) without any (visible) leak.
On the other hand, a small test programm like
class test
{
public static void main(String[] args)
{
while (true) { new Integer(0); }
}
}
indeed crashes with a segmentation fault after about 600.000 iterations (1.3
seconds) on my system (regardless of any -Xmx setting), so there IS obviously
a problem -sigh-. But it doesn't seem to be related to a memory leak:
-verbose:gc shows that after the second GC, every GC frees exactly 23523
objects/188.864 bytes and finishes with exactly "665320/838856" free. And at
the time the crash occurs, the application size is only 6 MB.
MbG, Ekkehard
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
