RE: maximum memory for gcj-compiled executable?

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

>>>>> On Unix-like systems we can constrain the maximum memory usage
>>>>> of a process - without cooperation from that process.

Nice tip. How can I institute such limit on Linux Red Hat 8.0? We're
planning to move the servant to linux anyway. I started out with win2k, but
now everything, including SWT-related stuff, compiles on linux too.

But such limit institutes a risk too. If the process really needs additional
memory (even after collecting), it will crash. I wonder if anybody has
thought about the problem of running multiple processes simultaneously that
don't collect their trash until starvation. They end up consuming all
memory. What if I start a new process in such situation? How can it signal
to the earlier processes that they must collect their trash? It really
sounds intractable.

I begin to dislike the idea that these processes hang on to large chunks of
memory filled with garbage. I'd rather they release resources as early as
possible. That would truly solve the problem.

>>>>> Doesn't Win2k have something like that?

I guess it doesn't; I googled on it for hours, but I couldn't find anything.

>>>>> If the amount of data is really
growing, setting a maxheapsize won't help - all it can do is
abort if the max is exceeded.

All memory allocations are referenced by local method variables, which go
out of scope at termination of the method. There is no way they could hang
on to memory -- unless the com.mysql.jdbc connection variable hangs on to
memory. Otherwise there are no class field variables that could hang on to
allocations.

>>>> It sometimes help to carefully null out fields or variables that
>>>> might point to data strcutures that are no longer needed. (I
>>>> have't been following the discussion, so perhaps my suggestions
>>>> are redudant or irrelevant.)

In my impression, there's no way it could hang on to memory. Since the
server is just one class, I could send you a copy, if you're interested. It
creates a thread to accept an xmlrpc request, invokes a number of sql
queries on the mysql backend, and then sends the result back to the client.
At this point all request-related memory allocations can be released. It
doesn't cache anything (at this point). I was planning to cache commonly
requested information in order to unload the database backend. At this
point, however, given the memory allocation/release problem, I wouldn't
dare.