maximum memory for gcj-compiled executable?

Tue Apr 1 01:28:00 GMT 2003

>>>>> There should not be any unbounded memory growth.

I think I did something wrong in the server process by closing the jdbc
resultset, but not explicitly the jdbc statement. When I look at the source
of com.mysql.jdbc.Statement.close() method, I can see that it releases quite
a few references explicitly. Now the growth of memory consumption seems much
more normal. Unfortunately, I cannot jump to conclusions and say that all is
clear now. Server processes may run for a very long time, and even a minute
memory leak could cause serious problems.
>>>>> Tracing garbage collectors inherently should not reclaim memory until
they believe that a certain fraction of the heap
>>>>> contains garbage. Otherwise the garbage collection time overhead
becomes excessive. If you need to use 100% of the
>>>>> heap for application data, a tracing GC won't give you acceptable
performance. With the current libgcj and default
>>>>> parameters, you might hope for something like 60-70%.

I understand the tradeoff; and 60-70% should be reasonable. I wouldn't need
100%. I would just appreciate the ability to guarantee somehow that there
will be no unbounded memory growth in a server process. I guess that this
would require advanced source code analysis?