maximum memory for gcj-compiled executable?

[Erik Poupaert]

>>>> To answer Eruk's question:  The compiler command line is processed
>>>> multiple times.  First it is processed by the gcc "driver" program,
>>>> which is builtr using gcc.c and java/jvspec.c.  That then invokes
>>>> jc1, where it is processed in toplev.c, but it call various
>>>> helper routines.

I would need commandline options initheapsize=... maxheapsize=... to keep a
lid on the memory consumption of a gcj executable. For a GUI it doesn't
really matter, but the current unconstrained memory consumption is quite
dangerous for server processes. I've been informed that my xmlrpc servant
quite likely brought down the win2k server on which it was installed. In
absence of free memory, the server wasn't doing any useful work any longer.

After re-producing the problem on my laptop, I believe its possible, since
nothing gets collected in a gcj-produced executable until all memory is
exhausted, starving the server from resources. When other processes on the
server request additional memory, the server gets heavily into trashing. The
gcj executable brings overall server throughput and performance to a
standstill. Adding memory doesn't help. It just gets filled up with trash
(very quickly). It's a nightmare.

Another question revolves around the fact that you have to allow a gcj
process to produce quite a bit of garbage, if you want any performance from
it. Otherwise it could spend much of its time garbage collecting. I wonder
what the characteristics are of the tradeoff? How is the curve of %garbage
versus %performance? For example, what is the percentage of your server
memory that you must allow the executable to turn into trash in order to
retain 50% of its clock cycles for useful work, as opposed to collecting
garbage?