RE: maximum memory for gcj-compiled executable?

["Erik Poupaert" <erik dot poupaert at chello dot be>]

>>>>> 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?